search

lxc / linuxcontainers.org

The linuxcontainers.org website
https://linuxcontainers.org
Other
96 stars 118 forks source link

[Question] Language Policy #722

Closed toby63 closed 6 months ago

toby63 commented 6 months ago

The request for indonesian language made me wonder what goal you would like to see regarding translation.

So would it be desireable to have full translation, including Documentation and Manpages etc.?

I often think, that certain things are changing very fast, so it might be impossible to keep up.

Also some kind of status report of different translations would be great, e.g. KDE provides info about how much percent is translated. Edit: Just saw that Incus links to weblate site, that does not seem to be available at the moment.

stgraber commented 6 months ago

For the website, we're happy with any translation as the website will automatically flag pages that are outdated anyways so the user will know that they may need to look at the original.

For documentation, it's generally harder to handle as that can be rather massive. Some very dedicated teams like the Incus Japanese team can handle that, as seen at https://incus-ja.readthedocs.io/ja/latest/

For the manpages, for LXC, they change so little that they can be translated in place and that's generally been done for a variety of languages either in our repo or in the distros directly.

For Incus, things move so fast that manually written manpages just aren't a thing, instead the CLI supports translation through weblate (at https://hosted.weblate.org/projects/incus/) and those translations can then be included by the distributions. That means all the --help stuff can be translated and in theory manpages can be generated from that output providing manpages in different languages.

https://hosted.weblate.org/projects/incus/cli/ has all the usual language statistics for translations.

toby63 commented 6 months ago

:thinking:

  1. Ok, so we only have overviews for the CLI translation. It would be an idea to add more content to Weblate or something similar, but I don't know how easily that would be possible, or whether you would want that.

  2. Regarding the documentation, where would the translations go to? You linked to the japanese version, which seems to have a seperate website for it. Could we also have a version like examplepage.de.md in https://github.com/lxc/incus/tree/main/doc or do you want that to be completely seperate?

  3. Also another "issue" came to my mind, when I looked at the CLI translations. In german for example, we often use english words, especially for technical stuff. Lets take for example the word "Container". There would be several german translations for that, but they would not make much sense, because people would not know what it means exactly and they would also not be able to make the connection to the english word "container". The problem is now, that the situation is not always clear, so potential translators would probably need to communicate about border cases with both the team (you) and maybe the community (if available) what would be best to do.

  4. The reason I am asking these questions is for two reasons:

    • I would maybe provide at least some translations.
    • I would like to add a "guide for translations" so that interested people can see, what is where and how things are expected to be done.
stgraber commented 6 months ago

2. Regarding the documentation, where would the translations go to?

Currently we don't have a way to do that inside of the repo in a way that makes sense with the Sphinx building process, so the best is to do it like the Japanese team and publish things through a separate repo and website, then have the translated menu on the website point to that instead of the original.

3. The problem is now, that the situation is not always clear, so potential translators would probably need to communicate about border cases with both the team (you) and maybe the community (if available) what would be best to do.

Weblate has the ability to leave comments on specific strings and will automatically suggest similar translations within the project, so that's how that kind of stuff is supposed to be handled.

4. The reason I am asking these questions is for two reasons:

So far, we've seen less than 6 indivduals contributing to translations total across all languages, so I don't see a strong need to codify things at this stage.

What we really need to get for now is one language having full translation coverage of the CLI so we can make sure that we're not missing some random strings in the code.

Japanese has been a good candidate for that also because of it being very visually distinctive and so making it trivial to check that no obvious string has gone unexported.

Once we reach that milestone, we can then really start ramping up on the quality and make more use of Weblate features to keep things consistent going forward.