Why I no longer will use App Text

[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.