i18n

[ctem]

Is your feature request related to a problem? Please describe.

There is a growing sentiment to implement internationalization (i18n) and localization (l10n) in and around the Nix Ecosystem for purposes of both UX and global adoption in general. Most recently, there has been discussion within the Summer of Nix program to contribute to this effort (which is backed by the European Commission, who have highlighted i18n and l10n collectively as an area of consequence). With nix itself at the core of the ecosystem, this seems like the appropriate place to start.

Describe the solution you'd like

I’m opening this issue to gauge interest among contributors in implementing i18n in the nix tooling. Opinions regarding preferred translation frameworks (e.g., GNU gettext, or possibly something else, depending on technical and licensing choices) would also be greatly valued. Whatever is decided here will undoubtedly influence implementation choices in other areas of the ecosystem as well.

Additional context

The goal is to allow localized strings to be output to the user. With nix, such output includes:

• inline output (e.g., error messages)
• documentation (e.g., man pages)
• Nixpkgs output (e.g., package descriptions returned from nix search nixpkgs)

While the first two categories suggest (depending on the implementation) modifications exclusive to this repository, the third category suggests the combined effort of implementing:

• l10n infrastructure in Nixpkgs
• i18n in nix for compatibility with said infrastructure

Thanks for your time!

cc: @armijnhemel @cab404

[leenaars]

This makes sense to me. Within NGI Zero we work a lot with Weblate (which is already packaged within Nixpkgs).

There are some recommendations as part of our https://nlnet.nl/NGI0/#bestpractices but we can also haul in the experts from Translate House (https://github.com/translate) to give you targeted advice.

[armijnhemel]

What might be worth noting is that making sure that every tool that has been translated can also output data as structured data that will be identical for every locale. There might be users that are currently relying on parsing stdout and stderr output, which could get caught by surprise or whose tools would not work in a different locale. By having consistent structured data output there would be a migration path away from this situation.

[tomberek]

This seems like a large task, the first step of which would be to improve the standardization and structured output of the existing implementation. After that there will be a fair amount of restructuring many portions of the nix codebase to accommodate, without breaking things. Along the way one would also want to improve the output and provide a few output targets. I do not doubt this would be beneficial, but would require targeted dedication by someone to make it happen. This year's SoN does have documentation as a focus, and that seems to be productive - additional investment into i18n/l10n can have a significant benefit. Overall: excellent idea, requires someone's focus to implement.

[toraritte]

I believe that any work on this will also positively affect efforts on documentation. Would tools used for the semantic web and natural language processing help? (At least, reading this issue made me recall this part of a talk). They have the benefit of being highly structured, but without creating ontolog(y|ies), taxonomies, etc. of the Nix domain not sure how useful they would be - and as Tom put it, it is a huge task. Albeit, the benefits could be immense for documentation purposes. (Then again, I'm only an enthusiast in this field so I may be totally wrong.)

[armijnhemel]

This seems like a large task, the first step of which would be to improve the standardization and structured output of the existing implementation. After that there will be a fair amount of restructuring many portions of the nix codebase to accommodate, without breaking things. Along the way one would also want to improve the output and provide a few output targets. I do not doubt this would be beneficial, but would require targeted dedication by someone to make it happen. This year's SoN does have documentation as a focus, and that seems to be productive - additional investment into i18n/l10n can have a significant benefit. Overall: excellent idea, requires someone's focus to implement.

Would you agree with that a first good step would be to investigate which tools in Nix do not output structured data?

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/summer-of-nix-documentation-stream/20351/2