nyxt
nyxt copied to clipboard
atlas-engineer
Internationalization
For now Next is fully in English. It would be nice to add support for other languages too. I wonder if there are internationalization libraries for Common Lisp. Maybe gettext support?
Adding internationalization support will fragment the discussions and support someone can receive. The UI should stay in one language for the sake of documentation and community support. Example: someone with Italian UI posts an error they get with Italian error messages and commands, same exact error happens to a Japanese UI user, now they will have no idea they have the same issue. Additionally we have no way to audit foreign language translations other than the ones we speak- most of the translations will be incomplete as we continue to add new prompts and commands. Thoughts?
Translation matters for many users uncomfortable with English. It can be a deal-breaker for them.
Also it's part of the "accessibility" concern, see NLNet :)
We can have a "report-bug" commands that disables translation. Then we are all good.
Manuals can be translated by community effort.
I’m OK with implementing the facilities for supporting translation and translated versions insofar as we do not maintain any translations ourselves and in our source, I don’t want to carry any of this liability
Usually translations are managed by a translation team (one team per language) quite isolated from the programmers. All bug reports and discussions regarding the translations go to the translation team, not the programmers. The programmers simply accept the final decision of the translation team. From the gettext manual at https://www.gnu.org/software/gettext/manual/html_node/Prerequisites.html
It is worth adding here a few words about how the maintainer should ideally behave with PO files submissions. As a maintainer, your role is to authenticate the origin of the submission as being the representative of the appropriate translating teams of the Translation Project (forward the submission to [email protected] in case of doubt), to ensure that the PO file format is not severely broken and does not prevent successful installation, and for the rest, to merely put these PO files in po/ for distribution.
As a maintainer, you do not have to take on your shoulders the responsibility of checking if the translations are adequate or complete, and should avoid diving into linguistic matters. Translation teams drive themselves and are fully responsible of their linguistic choices for the Translation Project. Keep in mind that translator teams are not driven by maintainers. You can help by carefully redirecting all communications and reports from users about linguistic matters to the appropriate translation team, or explain users how to reach or join their team.
Maintainers should never ever apply PO file bug reports themselves, short-cutting translation teams. If some translator has difficulty to get some of her points through her team, it should not be an option for her to directly negotiate translations with maintainers. Teams ought to settle their problems themselves, if any. If you, as a maintainer, ever think there is a real problem with a team, please never try to solve a team’s problem on your own.
Also, see the Translation Project.
Regarding gettext libraries for common lisp, https://github.com/rotatef/gettext seems interesting. It is a port of the gettext runtime to Common Lisp. It requires no C libraries.
I think any time we have a user facing string (in the UI) we can have something like
(with-translation-string (bookmark-save-prompt "save a bookmark"
.... body)
and then that will populate some sort of structure where we can use the symbol bookmark-save-prompt so that a user can customize it or install a translation set.
It could be something like
(set-translation 'bookmark-save-prompt "Sichern Link")
A translation would therefore just be a set of set-translation forms, or one very long one in the style that you seem to like :-D
(set-translation
'bookmark-save-prompt "Sichern Link"
'bookmark-delete-prompt "Loeschen Link"
...)
It could be something like
(set-translation 'bookmark-save-prompt "Sichern Link")
Unfortunately, natural languages can have very complex plural forms. So this may not be sufficient. See the gettext manual at https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html
Another issue is context. Sometimes the same English string might have different translations in another language based on the context. See gettext manual at https://www.gnu.org/software/gettext/manual/html_node/Contexts.html
Also, the use of gettext PO files has the benefit that translators need not be programmers who know how to write lisp. Existing translation teams, translation platforms already handle PO files well.
It could be something like
(set-translation 'bookmark-save-prompt "Sichern Link")Unfortunately, natural languages can have very complex plural forms. So this may not be sufficient. See the gettext manual at https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html Another issue is context. Sometimes the same English string might have different translations in another language based on the context.
That's why I specified each prompt or string would have a translation. Notice that in the above example I have said there will be a with-translation-string macro which accepts a string, not a variable. We can't reuse the same english translation over and over, each prompt in the text is unique. This means that the translator can translate every single prompt and piece of text uniquely.
See gettext manual at https://www.gnu.org/software/gettext/manual/html_node/Contexts.html Also, the use of gettext PO files has the benefit that translators need not be programmers who know how to write lisp. Existing translation teams, translation platforms already handle PO files well.
I don't know what PO files are, but we could support them as well, no problem :-)
@jmercouris: I think there is no need to reinvent the wheel here: cl-gettext provides everything we should need, included the string substitution macros.
OK, I haven't looked too far into it, I just read the README. It doesn't hurt to give it a try!
Before anyone gets too attached to gettext, Project Fluent is something I think would be important to take a look at. It's a research project backed by Mozilla, but I think it shows promise. Sadly I can't find any CL bindings or libraries, but there are JS and Rust libraries. I'm pretty sure Servo would be using it.
Other options:
- https://notabug.org/cage/cl-i18n
- https://github.com/dkochmanski/translate
