Changing language does not update name of "Trash" until reloading the page

[AtkinsSJ]

To reproduce:

1. Open Puter locally
2. See that there's a Trash icon on the desktop, and a Trash on the taskbar
3. Change language to Dansk (or anything really)
4. See that Trash is still "Trash" in both places
5. Reload the page
6. Trash is now "Papirkurv" (or the name in whatever language you chose) in both places

This might be a general problem with text not updating, I don't know, but this was the most obvious example.

[SaiUddisa]

Names appear when hover over the taskbar are always remains in English and apps in the start menu are also remains in English

[jelveh]

This is a good first issue. I'll wait a day or two to see if somebody picks it up, otherwise I'll fix it.

[SaiUddisa]

Can you give me a hint, where to start looking👀

[jelveh]

• Hard-coded instances of the Trash must use the i18n(). This is one example of the word Trash being hard-coded, this should be changed to i18n('trash').
• i18n() must wrap translations in a span with a special class, e.g. <span class="i18n">.
• ChangeLanguage should use the i18n class from previous step to swap out all translations. It would have to loop through all spans having class i18n and then change their content to the new language equivalent.

Let me know if you need help with this. Even though this may seem like just a bug fix, it's actually going to make the i18n module more powerful.

[ehsan-ashik]

I was going through the codebase, trying to understand the i18n and ChangeLanguage functionalities to brainstorm how the expected changes would work. From my understanding, the converted return value from i18n can be passed with wrapping <span class='i18n' key=${key}>${str}</span>, which would allow grabbing the elements from the ChangeLanguage functions and replace their innerHTML accordingly. This does work, as @jelveh suggested.

However, I was wondering whether directly changing the return value of the function i18n from text to an HTML element (span) can impact the overall behavior of the application, as the string value from the function can be set as the plain text title or tooltip text for different windows and UI elements, sometimes with calling the html_encode function, showing the output of the span tag as the value. Please see the image below:

Towards fixing this, I can think of two ways:

1. Change the calls of i18n() to accommodate the new change when applicable so that it always gets treated as an HTML element, not plain text. (I tried this approach and figured out the required changes for some of the UI elements, but there might be other elements that I still need to include).
2. Modify the function i18n() (or create a separate function altogether) to take a new parameter (let's say: returnHTML = False), return the tags for the function calls that ask for an HTML element, and return a string value for the rest.

There might be a better approach to solving this issue that I am missing.

@jelveh, I would love to hear your thoughts if you get a chance to see this.

[jelveh]

Thank you @ehsan-ashik, this is a good point.

I'd say in most cases (1) is the way to go. But there are circumstances where plain text needs to be returned (e.g. throwing errors) so we also need (2). So we need to go through the code and modify on case-by-case basis. @SaiUddisa are you working on this? If not, maybe @ehsan-ashik could pick it up. Otherwise I could do it...

[AtkinsSJ]

There might be a better approach to solving this issue that I am missing.

Another option might be to replace the i18n("foo") function with setting a data-text="foo" attribute on elements that should be translated. Then you can grab every element with a data-text attribute, and set its text to the translation. The downside is this wouldn't work for places where the text itself is needed, but we could keep the function around for those situations maybe.

(It's recommended that custom attributes start with data- to guarantee they don't conflict with real attributes added in the future.)

[ehsan-ashik]

Thank you @jelveh and @AtkinsSJ for your input. If @SaiUddisa is not working on the issue, I can pick it up.

[SaiUddisa]

@ehsan-ashik Please pickup this issue. Iam little busy right now to work on this issue.

[jelveh]

@ehsan-ashik I'm assigning this to you. Let us know if we can help!

[ehsan-ashik]

@jelveh, I will work on the issue based on the feedback from you and @AtkinsSJ . I will inform you if I need any help.

[ehsan-ashik]

Hi @jelveh @AtkinsSJ, I have created a draft pull request with the changes to update the i18n module as per our discussion. Here is a summary of how I implemented the changes:

• I added a new parameter to the i18n() function named return_html, which is true by default. From my observation, the title property for the UI elements (e.g., UIAlert, UIWindow) expects plain text. Hence, I changed the calls from i18n('foo') to i18n('foo', false), which returns a string from the function. To accommodate for the language change, I updated these elements to accept a new field, named i18n_key and updated the relevant UI elements to include i18n class and data-i18n-key attribute, which is set based on the i18n_key.
• For the rest of calls that set the return value of i18n() to an html element (such as button, label, html etc.), simply returning the html from the i18n() function does the job.
• In the ChangeLanguage function, the elements with the i18n class are grabbed and their relevant attributes are replaced (e.g., innerText, title, and data-name).

There might be items in the codebase with missing i18n calls or with incorrect keys (e.g., i18n('OK') calls in UIPromot, which I believe, should be i18n('ok')), which I did not include in this PR. Some other UI elements that are handled differently might need the i18n class or the attribute addition.

Please let me know your feedback on the PR and whether I need to change or include anything else.