[RFC] CLI localization story

[gribnoysup]

Change Type

• [ ] Feature
• [ ] Chore
• [ ] Bug Fix
• [x] RFC / Hopefully a feature 😄

Change Level

• [ ] major
• [x] minor
• [ ] patch

Further Information (screenshots, bug report links, etc.)

This PR is a request for comment/feedback for a CLI structure in relation to localization that I was thinking about for a few days. I was reflecting on this comment by @ceejbot and this issue: https://github.com/entropic-dev/entropic/issues/115

So the implementation in this PR tries to follow a few things metnioned in the linked comment and issue:

• Moves translation strings out to configs so it's easier to integrate later with some fancy UI if needed
• Clear structure: commands all have a corresponsing toml file with help (and any other metadata if we need this for something else), as toml files are named as commands, they are nicely sorted together is a file tree. Common translation strings used across commands are in one separate file
• Easy to add translations
• Easy (opinionated) to use translations in commands
• Disconnected from the topic of how to run commands, can be used with anything that we decide on later
• Minimal implementation, no new deps 😸

I moved all existing help files to the new setup, added Russian translations, and also added a few translated strings as an example of how it would look like

Why toml?

I was thinking about different file formats that we could use, toml seems like a good match for us:

• We already use it in CLI
• Allows for multi-line strings
• Holds more structure than a .txt file
• Allows for interesting ways to specify pretty readable (opinionated) translation structures (see cli/lib/localization.toml)

/cc @toddself because I changed your *.txt based implementation for help and would love to hear what you think about this, @ceejbot as I mostly based it on your feedback and I'm super interested how it aligns with it

[fetis]

I'm strongly against TOML format to store localization strings. It's not designed to store i18n information and supported by none of the translation platforms (like Crowdin, Lokalise etc).

Moreover, manually put strings for translation is tedious work. I woud suggestting keep strings in source code and mark them for translation. Extraction tool can automatically extract all string and messages for translation and upload it to a translation platform. I would suggest .po or .xliff as formats to store translations.

[gribnoysup]

@fetis makes sense! I'm looking through tools that are helping to extract translation data from the source code, maybe you have some recommendations?

Reagrding the formats, I quickly browsed through po and xliff specs, po seems like a nice choice, feels more readable than xliff for me, I kinda want to try using it now. Do you have additional feedback on the format, like pros/cons, what would you prefer out of those two?

[fetis]

@gribnoysup .po is a relatively old format, introduced by Linux utility gettext. XLIFF is an XML format and it's accepted as an industry standard.

I personally would prefer to have XLIFF export because of XML nature. You can transform and modify XML documents with XSLT transformations (in case we'll need this)

I think we need to continue our discussion in the issue #115