Interface should be multilingual

[Popolechien]

As part of the zimit 2.0 project and as a requirement from the project's sponsor, we need to make the youzim.it page available in farsi.

The number of strings is fairly limited and I can probably find a helpful native speaker to review or even do translations, but is there any specific process?

[rgaudin]

UI is not localized ATM.

[benoit74]

Do we have a standard for this kind of localization? Some file format / library is preferred so that it is compatible with TranslateWiki?

[rgaudin]

No. We've never localized a Vue app before and there's an additional difficulty: we're retrieving form details from zimfarm.

I don't know if there are conditions for TW acceptance (beside license) ; should maybe be checked.

[benoit74]

Yep, the additional difficulty is not a small thing. This means we should work on openzim/zimfarm#886 first, probably.

[kelson42]

I see the difficulty to implement a full localisation considering the strings come from different sources. So, can we focus this issue on just translating what is handled within this repo?

[Popolechien]

Yeah I don't think we need to have zimit itself translated (nor the zimfarm UI), but merely the web portal: Title, two field boxes, Launch button and FAQ.

There may be a discussion about how much access to advanced options we can expect the users use/want/need (last time I think there was agreement that these weren't very useful for the average Joe), but even then it's two dozen strings.

[benoit74]

While I agree that "advanced options" are not all important, mastering some of them is mostly mandatory to ensure you get a the ZIM with the content you intend to scrape (e.g. scope, include, exclude) ; maybe some advanced options shouldn't be considered advanced ones.

[kelson42]

@benoit74 Agree, at least for the moment. But so far I see no real elegant solution to that problem. Lets already move forward with our two tickets and then we will see.

[benoit74]

@benoit74 Agree, at least for the moment. But so far I see no real elegant solution to that problem. Lets already move forward with our two tickets and theb we will see.

If we agree that we will localize and translate all zimit usage as part of openzim/zimfarm#886 (which is what I understood yesterday), then I'm fine. My remark was only a reaction on the assumption that we might want to translate only the UI and the 2 main combobox, which is insufficient from my PoV ; if we translate all, then I'm fine.

Do we all agree on this?

Second point: do we agree that translating to farsi also means supporting right to left orientation?

[rgaudin]

Do we all agree on this?

I understood we start with just what's in this repo.

And obviously RTL must be supported

[OMAREID0]

Hello again,

I am looking to work on this open-source project if possible. I thought about this issue and did some research. I found that Vue doesn't have any libraries like Babel in Python. Therefore, the only way to translate the frontend into several languages will be through I18n. To use this plugin, you will need to store it in a dictionary so you can serve it when a user wants to change the language or even detect it from the HTTP header.

However, as you said in the GSOC, "we want to make sure that as many people as possible can use it quickly, without having to go through a translation dictionary first." So, what method do you want to work with?

Thanks

[benoit74]

Yes we want to i18n the application, we do not want automated translation. For translating the English strings in various languages, we will rely on TranslateWiki folks. All strings will be stored in the repo in a dedicated folder, with one file per supported language. The file format is not yet known, will depend on the library probably (could be JSON since we are in JS, but also anything else which makes sense for the library, e.g gettext formats)

The plan to solve this issue is hence:

• decide on a library for i18n of the Vue.JS application
  • https://vue-i18n.intlify.dev/guide/advanced/lazy.html seems to be one potential solution, but we need to compare it with other alternatives
• implement the library by transferring all English strings to a dedicated file and source them from this file
• add a second language of your choice with at least few translated strings
• add a button in the UI to select the language + automated detection of proper language based on user browser language + incentive to collaborate on translation to add more languages / cover all strings with a link to TranslateWiki
• once ready, merge this change and release
• request integration with TranslateWiki (I will probably take care of that part)
• job's done, TranslateWiki will take care of regularly pushing translations to this repo

[OMAREID0]

Sweet! I will start by stadying and using i18n for this, and I will cover maybe three languages: Arabic, English, and some French. This way, I can ensure it's correct by using TranslateWiki. I will submit a demo of the JSON file structure for every language in the GSOC application, along with a UI for the button. I hope you like my work; it would be a pleasure to work with people like you. I am willing to acquire every piece of knowledge I can from the entire team. Thanks!

[benoit74]

Some remarks:

• discussion about the choice of Vue.JS library will have to take place at Define a convention for i18n of Vue.JS applications overview#28 since we want this choice to be made for all our Vue.JS applications
• TranslateWiki is a collaborative platform for translation, it does not perform much checks, so I don't get what you want to ensure with it in terms of correctness
• while we can't expect that you solve a whole GSoC project before it starts, do not forget that we need you to have successfully submitted few PR (at least one) on smaller issues so that we can ensure you know to code and collaborate with us properly

[benoit74]

Closing this in favor of #76, code is ready and deployed.