• the manual

I was presented with the following SoN issue: "i18n and l10n are a big part of NGI0. Nixpkgs currently doesn't support this." The following is an excerpt from my response after an initial assessment:

I think this could do wonders for Nix ecosystem adoption in general. However, the scope of this particular issue is not quite clear to me, making it difficult to curate. It seems that all actionable tasks fall under the category of generated documentation, targeting the following components:

• Package descriptions
  • Use case: nix search nixpkgs returns a list of packages with their descriptions (i.e., the value of each package’s lib.meta.description attribute). This could be expanded to accommodate descriptions for other locales (e.g., lib.meta.description.ja_JP or similar), defaulting to en_GB (or en_US, etc.), such that the locale specified by the user’s system (perhaps overridable by a new nix search option such as --locale) would be respected where available.
• Module descriptions
  • Similarly, module man pages are generated from exposed option attributes such as description and example. Expanding these attributes as described above could allow generation of locale-appropriate man pages.

While I would consider it out of scope for this issue, the effort could be rounded out by implementing i18n for:

• The man pages for the Nix commands themselves
• Web content
  • NixOS search
  • Manuals
    • Nixpkgs
    • Nix
    • NixOS
  • NixOS general website
  • Any other associated documentation
• ...

A note regarding NixOS itself (as opposed to its documentation): I don’t see anything to be done. With the existing impl, it seems that most use cases are accommodated:

• The i18n module allows the system to support multiple locales. (Whether a given program supports a given locale, however, is a program-specific concern.)
• The fontconfig module allows default fonts to be set for programs that support Fontconfig.
• The font attribute of the console module allows for virtual console font substitution.
• Many high-quality fonts including glyphs for many languages are packaged.
• Keyboard layouts are configurable (e.g., with services.xserver.layout and console.useXkbConfig attributes).
• The i18n module additionally provides Input Method Editor (IME) (e.g., fcitx) support.
• Somewhat relatedly (to the overall localization experience):
  • The locale module allows the time zone and geographic coordinates to be set.
  • Multiple services for time synchronization (e.g., chrony) are available.

Prior art:

• Home Manager introduced basic i18n support through gettext with Weblate-hosted translations. The effort is divided into three categories: CLI, modules, and glossary.

In reply to @profpatsch:augsburg.one
ctem: I recently learned that DeepL supports a glossary, so even if you wanted to translate the manual, you could give it a list of nix terms and their technical translation and let it translate the “stuff in between” automatically

In reply to @whentze:matrix.org
do we expect people who don't know english to be able to contribute back, including docs? if so, and if the authoritative version of docs remains english, how do we do that? deepl backwards also?

This exposes the more fundamental issue that contributions have to be prepared in a language that maintainers can understand. As with the typical statement found in legal documentation—"In case of discrepancy between the English version of these Terms and any translated version, the English version shall prevail"—documentation translation contributions (e.g., via Weblate) tends to be based on an ‘honor system’ because maintainers can’t confirm accuracy with complete certainty.

For that reason, I think it’s reasonable to expect contributors to have a level of fluency in the project’s dominant language.

In reply to @whentze:matrix.org
do we expect people who don't know english to be able to contribute back, including docs? if so, and if the authoritative version of docs remains english, how do we do that? deepl backwards also?

This exposes the more fundamental issue that contributions have to be prepared in a language that maintainers can understand. As with the typical statement found in legal documentation—"In case of discrepancy between the English version of these Terms and any translated version, the English version shall prevail"—documentation translation contributions (e.g., via Weblate) tend to be based on an ‘honor system’ because maintainers can’t confirm accuracy with complete certainty.

For that reason, I think it’s reasonable to expect contributors to have a level of fluency in the project’s dominant language.