OpenBMC GUI Design Workgroup - Today 10:00 AM CST

Joseph Reynolds 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 ~
>> https://lists.ozlabs.org/pipermail/openbmc/2019-November/019422.html).
> 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.

- Joseph



More information about the openbmc mailing list