Discuss.FOLIO.org is no longer used. This is a static snapshot of the website as of February 14, 2023.

Language Switching Button on the top FOLIO bar

kwareict
1 Mar '19

Hi,

I wish there is a button on the top FOLIO bar that enables users to switch to another language by clicking on the button and a drop down list will show all available languages set by admin of the instance to switch too. This way users do not have to go Settings > Organization > Language & Localization > and then select the language > and then press the Save button > and then have to go back to where they had been at before… if they are lucky having a good memory. Just Kidding!

In our case, only Arabic and English languages are needed to toggle between them. Therefore, in most cases only these two languages are made available for users to select between them. To reduce the switching steps, more advanced bilingual UI displays only the other language icon (English language icon while in RTL and Arabic language icon while in LTR) at any time.

Thanks,
Massoud.

hanpengfei
6 Mar '19

Maybe local language settings could follow the current user’s login locale or registration area.

MikeTaylor
7 Mar '19

Hi, Massoud. Actually, what’s happening in Settings > Organization > Language & Localization is different: as the name suggests, it’s setting the default locale for the whole of the organization, and will affect anyone who logs in.

What you’re very reasonably asking for here is per-user locale setting — and you’re right that good UX for this would be an easy-to-find toggle at the top of the page.

Back when I was working on the FOLIO core, we had a plan to support user-specific settings like this, but I don’t know if it ever got implemented. Probably @zburke would know. (If not, it’s time it did!)

zburke
8 Mar '19

User-level and session-level settings are still a part of the plan, but I don’t know the schedule. I can tell you for sure it’s not this quarter; I don’t have any more specific details.

massoud
8 Mar '19

Thank you Mike for your clarification and support.

massoud
8 Mar '19

Thank you @zburke for the update.

Ann-Marie
8 Mar '19

Related Jira issues are UXPROD-510 (User-level locale and time zone setting) and UXPROD-883 (Localization and language should be separate settings allowing for [***ish] speaking users in FOLIO while keeping the locale settings.). Neither is assigned to a particular dev team or timeframe yet. Neither was ranked as needed by go-live by any of the early FOLIO libraries, so they haven’t been prioritized yet.

massoud
8 Mar '19

Thank you Ann for the status update.

filipjakobsen
9 Apr '19

Thanks for your comment, @massoud!

We definitely want a user-level language switcher. For practical reasons, we probably will not be able to put it directly in the top header, but we can put it in the User menu dropdown, which is in the top header on the far right.

I am attaching a draft for clarification.

massoud
19 Apr '19

@filipjakobsen I think this user-level language switching approach looks fine. It is does the job in a very practical way. Thanks.

massoud
24 Apr '19

Hello @filipjakobsen
When do you expect the user-level language switcher, as suggested in display above, will be implemented ? @Peter_Murray @Ann-Marie

Thanks,
Massoud.

Ann-Marie
24 Apr '19

Hi @massoud,

The relevant Jira feature is https://issues.folio.org/browse/UXPROD-510. The first FOLIO implementers have not ranked this as a go-live requirement, so there’s not a timetable associated with it yet. @peter - Any other thoughts on possible timing?

Thanks,
A-M

peter
25 Apr '19

I don’t have anything to add at this point.

ianibbo
26 Apr '19

Just one thought guys - I know the TC has a new definition of technical debt - This strikes me as one of those things where at-the-point you implement it, it has the capacity to touch every point in the UX. Therefore doing it sooner, and making sure that the individual components all behave properly sets up anything created afterwards to work properly. Deferring the work risks increasing the number of components that have to be retro-fitted when we do eventually do this work. I am aware that some may try to advance an argument that changing a component once will change it everywhere, however, our experience in searchAndSort seems to be that changes/enhancements to components ends up with UI app refactoring - therefore, I’d be interested to hear if this decision is covered by the TCs definition of tech debt?