Why I no longer will use App Text

[boston85719]

After implementing app text into my multi-language app, I’ve come to realize it was a mistake to use the App Text feature and I should have gone with my gut and implemented a translation via the Option Sets.

I believe others have posted in the past about option sets for translations instead of using app text. I was always hesitant because option sets can not be created dynamically or via CSV upload, but I believe plugin was released that does this, or its a chrome extension (I don’t recall, and have no association with it, but will search and find and try to use soon enough).

Overall, issue with App Text is that it requires the page to be refreshed for the app text to take effect when the user chooses to change the language.

What I have setup in my app is a way to use my url instead…for example the blog page.

www.myapp.com/blog

What I do is leave content type empty (can’t use it because of limitations with the data to send feature and having multiple languages). I add to the url the language so…

www.myapp.com/blog/th or www.myapp.com/blog/en

Then in my database, I use the built in slug field for the english version but for other languages I need to create a field for the slug in that language.

after the language I add the slug value corresponding to the language.

Then on the page, I use the search to pull up the correct entry based on the URL path item #2 being ‘en’ and use the format as text operator to add inline conditionals to determine which way to search (ie: search using the slug as constraint (for english - url path item#2 is en) and the languages slug field for other languages)…this makes it so the correct translated version is displayed (I have all the translations saved to the datatype).

Now, when a user will change their language selection, the workflow action will use the Go to Page Action to set the URL properly to the selected language. In this process the translation is super quick (pretty much instantaneous) and since the go to page workflow action doesn’t refresh the page, so custom states are not lost, the app text doesn’t change properly, resulting in poor UX…

So, now, I will need to use Option sets so I can have the same UX and quick change between languages of my dynamic content, as well as all the related static text that used to be App Text that I switch to option sets.

If the App Text feature were enhanced so that a page refresh was not necessary, I’d still be able to use it, but since it does require a page refresh, I can not use it and provide a great UX.

[mikeloc]

@boston85719

I was always hesitant because option sets can not be created dynamically or via CSV upload, but I believe plugin was released that does this, or its a chrome extension

I’ll save you a click or two.

[New Extension] Bulk import from CSV file for Option Set

Besides Option Sets is a very helpful feature and has a good impact on app perfomance, managing Options Sets is not as easy as it can be. So I decided to create Chrome extension which will help in working with Option Sets. Current version of the extension gives the ability to import Options from selected CSV file. I’m a newbie with Bubble, so I want to ask the community to help with testing and providing the feedback. Link: Bubble Option Sets Helper Aslo I want to ask which feature in Optio…

[BeePlusPlus]

Your subject line seems bit dramatic to me

I suppose you meant you would not use App Text for the use-cases that require changing url on the basis of language for the reasons you mentioned.

However, using App Text does make the expressions bit simpler. Using Option set would require to load full option set, filter it with language of the user and the text you want to show, choose the first item etc. making expressions even more cumbersome and complicated compared to what they look right now. Also, checking “user’s language” will have to be done with a local copy of user to avoid WU costs.

While using App Text all the computation is done at server end itself and page is just rendered to the user, which I suppose will make the experience bit faster and page lighter too to the users.

[boston85719]

@BeePlusPlus

I suppose you meant you would not use App Text for the use-cases that require changing url on the basis of language for the reasons you mentioned.

No, I actually meant I will no longer use App Text

@BeePlusPlus

Using Option set would require to load full option set, filter it with language of the user and the text you want to show, choose the first item etc. making expressions even more cumbersome and complicated compared to what they look right now.

No. While true, there is more to the expression than simply referencing app text, it is not like you explained.

As mentioned, I don’t use the ‘users language’ and I instead use the URL path item #2 (akin to a sub-folder for language - but within Bubble constraints). I don’t need to load all option sets (they are pre-loaded anyway as that is part of their built in function as being ‘universal’ and much faster to display than data types because they are already loaded and do not need to be retrieved)…also, I can just simply select the actual option I want to display…no filtering necessary.

@BeePlusPlus

Also, checking “user’s language” will have to be done with a local copy of user to avoid WU costs.

No. Don’t use users language. Uses URL path item #2.

It avoids the WU costs of loading a page and all of it’s data since the page is not having to be refreshed to display the newly selected language.

@BeePlusPlus

While using App Text all the computation is done at server end itself and page is just rendered to the user, which I suppose will make the experience bit faster and page lighter too to the users.

No. Experience is 1000 times faster when not using App Text for one main reason being there is no page refresh and a new page load taking place to show the newly selected language just to get the app text to change. Watch the video, it takes 1/2 a second to get the entire page language changed when not using the App Text and using the option set.

[BeePlusPlus]

Okay sure.

I still feel your use-case is specific to getting data from url, updating url etc.

I primarily have dealt with use-case of showing content on the app in user’s chosen language. For me refresh is not an issue in that case as language change happens rarely. And once done, it usually remains at that. And users can be expected to be fine with refresh when they change the language (in my case).

Also, I generally like to avoid putting too many conditionals like you have shown e.g. If language is th, then show Learn's Thai . I would prefer it to be more like All options translations: filtered 'where original text is <one variable> and language is <another variable>': first item's translated text

Now with this I get these advantages:

1. I would not have to write conditionals everywhere.
2. I have to just use same expression and change the text I want to show and language which also can come from another variable.
3. And I do not have to change the text also in every conditional. e.g. in your case I would have to change expression Learn's Thai and Learn's English etc. to Teach's Thai and Teach's English when I copy the Learn text to another element Teach
4. Also to introduce another language I do not have to go and change all the places and their conditionals. I have to just add some more option set items.

But then since this is also bit cumbersome, I like App Text for my use-case wherever possible.

[boston85719]

@BeePlusPlus

Also, I generally like to avoid putting too many conditionals like you have shown e.g. If language is th, then show Learn's Thai . I would prefer it to be more like All options translations: filtered 'where original text is <one variable> and language is <another variable>': first item's translated text

Yes, if I were building an app with more than the two languages, I may have taken the time to setup the option set for translations to use a variable from the option set that represents the language. My tip was not about detailing how to setup multiple languages in the app, but focused on why I won’t use App Text and why.

@BeePlusPlus

I would not have to write conditionals everywhere

Yes, you do limit the number of conditionals you would need to copy and paste onto the other elements.

@BeePlusPlus

For me refresh is not an issue in that case as language change happens rarely.

True, users primarily are going to be following links in their own language and if the app is setup properly the link should make it so the User’s language preference is ignored upon page load if the language of the URL is different from their language you saved in the DB, if you are using a database field to indicate which language should be used.

If you are using the URL parameter to indicate which language should be used, then no need for referencing the current users language. The problem with the URL parameter for language preference is that URL parameters are no good for SEO, so definitely not something to implement if your app requires SEO.

If you are using the users language preference as stored in the DB, and the user navigates to the app from a link that is set in a different language, you don’t want in your app any automatic redirects to the page to be shown in their language preference as this causes issues for SEO, mainly the fact that it is likely your pages will not be indexed by Google because of the redirects. I had the issue of my users language preference, which is set using a default value on the user data type, making it so that Google got redirected on page load because the link to crawl/index was in another language than what the default language field was set on the User. As by default the user field language preference was set to English, if the link to crawl/index was in Thai, and the setup of the app had an automatic redirect to show the app in the users language preference, then Google bot got redirected and page was not indexable.

What I have now allows me to set no redirects on page load to show the language in the language preference of the User data type, something I could have done with the language URL parameter, but the language URL parameter is not an option as SEO is of utmost importance for the app. Since SEO is important, the links use the language in the path list, and the language to display the app is set to reference the language in the path list, which can not be done with App Text.

With this setup, which requires the page content type to not be set, since I’m placing the language in the URL path list (where the page content type things slug or unique ID would normally go), I send text as the data to send, and my search page and my display page are the same…so if searching for products, the user is on the page called products with url something like www.myapp.com/en/products/men-shirts and if they have selected a particular product the url is something like www.myapp.com/en/products/polo-red-men-t-shirtso the switch between the search and product display is pretty near instant, since no page redirect is necessary. This setup can be done with app text in use as well, but definitely requires the language preference to use the current users language as opposed to the URL.

Overall, when developing I care a bit less about the ‘cumbersome’ nature of the development process, than I do delivering a good UX (speed to display chosen language even if it is infrequent) as well as optimizing SEO and overall performance of the app in terms of speed.

But you are correct, likely not everybody would find reason to go to the lengths I do to create the features/functions of the app to match the exact needs of the business, and at times putting less effort into the development process at the expense of UX and app performance may be to the developers benefit. In the end, I build my app for the user and the business to be successful, rather than trying to develop as quickly as possible.