Bilingual Ideas

[BlakeWS]

I wish I would have understood this 2 months ago!

[Darren_Murphy]

@BlakeWS

I saw what @Mark_Turrell is doing and I’m not sold on the idea of writing all the text within the app to each user row, it really seems redundant. (No offense intended, maybe there are reasons for it that I just don’t see yet. But in an ideal world I don’t think you would do this.)

None taken

However, that’s actually not how it works. All the translated strings are stored in a separate table, and dynamically loaded into the User Profiles table via computed (single value) columns depending on the users language selection. So none of the data is stored in the User Profiles table, just references to the data.

The advantage of having those references is that every translated string is available for use anywhere in the app without the need to create additional relations and lookups.

There is no redundancy in the User Profiles table, but yes there is redundancy in the strings table - as every user will get every translated string for every supported language loaded into that table. The upside of that is that it allows for instant language switching. But the downside is that it can be very expensive in terms of row count (bandwidth would never be an issue, as it’s just text). I’m aware that @gvalero devised a modified version of my approach that got around the row count issue.

I certainly wouldn’t suggest that it’s an ideal solution - I built that several months ago, and I’ve learned quite a bit (a lot) about Glide since then. That said, I’ve used it in a couple of apps now and it’s served me well.

[BlakeWS]

@Darren_Murphy

So none of the data is stored in the User Profiles table, just references to the data.

I just found out yesterday that the computed columns are on-device only, so this makes more sense - even if I see it in the Glide table…

@Darren_Murphy

The advantage of having those references is that every translated string is available for use anywhere in the app without the need to create additional relations and lookups.

Okay, I see how that would be very useful for commonly used words/strings. I have buttons that have the same text on multiple tabs, so this would reduce the columns required.

@Darren_Murphy

There is no redundancy in the User Profiles table, but yes there is redundancy in the strings table - as every user will get every translated string for every supported language loaded into that table. The upside of that is that it allows for instant language switching

The method I tried can also facilitate instant language switching, I think a hybrid between the two would work nice, with the method I used for unique words/strings. In any case, I’m happy that reasonable solutions can be made without the equivalent of spaghetti code.

One other thing, I think that having the ability to source text from a different table for the components than the table that is being written to would clean this up nicely. Just like how the choice component works. (But then in the case of a choice there would be three tables LOL.)

[gvalero]

Thanks @Darren_Murphy

To sum up my idea, I describe it here:

1. There is no need to load all words and their translations. If your APP has 50 words using 3 languages, the APP won’t load 50 or 150 rows at startup (none row is consumed/counted), the GS will do the hard work and assign to each user each translated word according to his preference.
2. Each key word (to be translated) will use a column and them will be created automatically in APP. I mean, if you have 50 key words, your APP will have 50 columns which hold the translated word associated to user language.

3. By using User Profiles table/tab on your APP, each user will have its own configuration and translation based on key word column.
4. If the user wants to change his language, the new value (language code) is sent to GS, the formulas will update and change key word’s value and Glide will show the new translation. This was done to not be dynamic because the user was going to choose his language only at the beginning and maybe it wouldn’t be changed later. If you are looking for a dynamic dictionary with a fast reply, I think, it won’t be your best solution.

It was created to be a Proof of Concept @BlakeWS, I would have to create a small APP to test all this but I think it will work. Again, all will depend of your use case but at least, it can give you other smart and wild ideas

Feliz día!

[BlakeWS]

Thanks for the detailed breakdown, @gvalero . I made my proof-of concept using Glides tables only, so it works much different. I try to avoid Google sheets as much as possible, but without data importing it would make long lists of translations difficult with GT only.

@gvalero

By using User Profiles table/tab on your APP, each user will have its own configuration and translation based on key word column.

I think that this isn’t necessary based on the comments from @ThinhDinh / @Jeff_Hager / @Darren_Murphy, plus my experience with the little app that I built.

@gvalero

If you are looking for a dynamic dictionary with a fast reply, I think, it won’t be your best solution.

Yeah, this is another reason I try everything I can to avoid GS.

@gvalero

Again, all will depend of your use case but at least, it can give you other smart and wild ideas

It’s great, I really appreciate it!. I’m going to build out further to see how things go with all the new info I have from the last few days.