About I18N and Translation Merging

[lllyasviel]

Hi all Fooocus Contributors,

Recently we have I18N system and many contributions are active. Thank you so much for the work!

One thing is that we just realized a problem about merging those files – if we merge a file into the repo, the updating system will overwrite that file of other users (if their file names are accidentally same).

For example, if I am using my own “jp.json” and the official repo also has merged a “jp.json”. The new “jp.json” will overwrite users’ language file. This is not a bad thing if the updated file is really newer. However, some people (or say, distribution maker) may want to maintain their translation and their offline translation files are usually newer than the files in this repo.

As a result, the consequence is that we should not merge any i18n json files to this repo right now. We will probably open another place to list a collection of language files. This may change in next updates.

This does not influence the functionality of I18N system.

Thank you for your support to Fooocus as always.

[diaolulu1]

You can set rules that require collaborators to add name suffixes, such as: chs_diaolulu.json

[xhoxye]

Or you can build a subfolder of the official merge under the language folder, and read the officially merged file when there is no file with the same name in the language folder

[zhongqingsong]

To clarify my identity, I lead and participate in the translation of many software and games. Some games and software can be found on my Githab homepage. This is mainly to explain that I have rich experience in both commercial translation and open source translation. And then these issues that you're talking about, in general, are concerns about the conflict between two users: the official and the user.

First of all, in order to facilitate maintenance, exclude the creation of new folders, these ways to solve some problems, but also bring new problems, which will bring trouble to maintenance.
Secondly, the current language management convenience is insufficient, simple use of en, cn and other abbreviations, will bring new problems, that is, the language between different regions. Such as simplified Chinese and traditional Chinese, European Portuguese and Brazilian Portuguese. So, I suggest using the internationalized language classification in this game example link: Instead of using letter abbreviations, use word abbreviations. This can completely solve the problem of language differentiation.
Finally, you are worried about official and user localization file conflicts. This can be solved using load priority, and official localization files are simply alphabetic files. Such as english.json, this is the official, priority loading. Then, others with numerical suffixes, such as english_1.json, english_2.json, english_3.json. Load localized files in order of the size of the file's suffix.

The final process is to first load the official translation english.json, then english_1.json, then english_2.json, and so on. In this way, the coverage of official translation is guaranteed; At the same time, user-defined translation files will directly replace the official documents. Whether users want to modify the official translation, or other developers want to provide a custom translation, they can do so.

[MoonRide303]

@zhongqingsong To be honest best way would be probably sticking to POSIX locale definition (stuff like "en_US", "en_UK", etc.), as that's the default method used in Python:

>>> import locale
>>> locale.getdefaultlocale()
('pl_PL', 'cp1250')

[Phrixus2023]

One json file for one country's language would be nice, and then we all work together to maintain it and review it officially, so as to avoid wasting resources

[zhongqingsong]

@zhongqingsong To be honest best way would be probably sticking to POSIX locale definition (stuff like "en_US", "en_UK", etc.), as that's the default method used in Python:

>>> import locale
>>> locale.getdefaultlocale()
('pl_PL', 'cp1250')

yes, you are right, You just need provide primary language support. It's the right thing to do. Then you can consider the form that applies the priority, such as en_US_1,en_US_2, This allows for a very smooth flow of text.

[lllyasviel]

and another problem is that in the future when new buttons are translated, updates will create pull requests and causing unnecessary workloads of contributors and approval delay.

Perhaps just setup a readme section with links to json files for people to download, and leave the folder blank

You can see that the language folder of Automatic1111 is blank

[lllyasviel]

AUTOMATIC1111/stable-diffusion-webui@ac08562

[thiner]

Yes, indeed. I think a better way to provide i18n ability is the ability only, not the vary outputs. E.g. provide the ability to read language configuration files from a specified folder, let user put in their language translation, and apply by selecting the file in a dropdown list. The translation quality is fully rely on user's choices, not this project.