OpenBMC GUI Design Workgroup - Today 10:00 AM CST
jrey at linux.ibm.com
Tue Mar 10 06:20:14 AEDT 2020
On 3/4/20 9:34 PM, Derick Montague wrote:
> Hi Joseph,
> Thank you for your feedback.
>> My two cents worth:
>> 1. Data should be stored untranslated whenever possible, and translated
>> only when it is presented to the user.
>> 2. It seems to me the language preference should ideally be associated
>> with the session (whether login session or a session to perform a single
>> operation ~
> 1. The GUI translations are stored in JSON files. Which content is determined
> by the Vue i18n Plugin.
That sounds good but covers only the GUI elements. I was thinking about
the human readable data that flows from the Redfish APIs into the
browser. For example, SEL data. Do you know if this data will flow
from the Redfish APIs as messageId and replacementText, similar to
Redfish messages? Alternately will the message already be formatted as
a single string when it flows from the Redfish API? <-- That was the
intent of my original cent (quoted above).
> 2. The language preference will be stored in local storage, so it will persist
> for as long as the user doesn't change the language or clear their browser's
> local storage. The question is whether the user should have to log out if they
> want to change their preference.
I understand your response to mean: the user's language preference is
stored in the browser's local storage and presented to the BMCWeb server
in form of something like the a HTTP request Language header (whatever
the current practice is). That sounds okay to me. In any case, I think
switching languages is infrequent. That is, I do not foresee a user
requirement to switch language frequently during a single signon session.
More information about the openbmc