[Web] Add language setting into the parameter in the url (e.g. https://app.gametize.com/lang=es)

Reviewed

Comments

1 comment

  • Avatar
    Lee Chuan Xin

    I tagged this as 'For Consideration' / 'Answered' for now, because it actually involves quite a major change in code structure for what I believe to just be a minor improvement in user experience.

    Structural Context

    Right now, the routing in app.gametize.com supports parameterized URLs, but only in a strict order it is written. For example, https://app.gametize.com/project/826/category/1008 will lead you to a Project ID 826 and Topic Category 1008, but https://app.gametize.com/category/1008/project/826/ is not going to lead you anywhere.

    lang parameter, in my opinion, should be agnostic to the order it is written. Unfortunately, we cannot support this for the time being without major structural changes to the routing code.

    Besides, your language settings on app.gametize.com are currently stored in localStorage. In layman, it means you can log out, close your browser, turn off your computer, and come back and the existing language settings will still be in play (as long as you do not clear your browsing history or cache).

    With parameterized URLs, we also need to think about default cases. Imagine that I have previously set my language to Spanish, ie. it is now stored. What happens if I use https://app.gametize.com/project/826 instead of https://app.gametize.com/project/826?lang=es?

    Should a URL without the lang parameter allow me to continue using my previously set language, or should it return to the default language (in the case of app.gametize.com, your own browser language)?

    Key Question to Ask

    My interpretation now is that this will just be a minor improvement in the user experience. I will be curious to know if there are observed problems with clicking on the globe interface to change the language.

    Assuming we are either keeping the existing interface or using the URL approach (having both will be trickier to maintain; a lot of entry points and variables to account for and a longer time to re-write), I would prefer the former.

    The latter involves the visitor actually knowing the string to be used in the parameter (eg. 'en', 'es', 'zh-Hans', 'zh-Hant' etc), while the former only expects him/her to recognise what the language looks like (in the Language Selection pop-up dialog).

Please sign in to leave a comment.