Open epage opened 6 years ago
GNU GetText style _
for i18n?
@pickfire: That's definitely a necessary part of the complete picture!
Another thing that would be really important is to have a way of relating localizations of the same content to each other, with a default language as fallback for nonexistent localizations. Hugo does a good job presenting an end-user spec here: https://gohugo.io/content-management/multilingual/
Those are the two main parts needed to fulfill this use case for static sites. A little static JavaScript could be used in tandem with the aforementioned information to redirect users to the correct localization for a page -- not necessary, but an interesting feature to build on top of the previous two.
Note that I've written a RFC for i18n in Gutenberg: https://github.com/Keats/gutenberg/pull/111 Not implemented yet but is similar to the approach Hugo is using, which is quite good IMO
@Keats The one I was talking about are most possible in the alternatives section though where we use one file to do multiple language, I didn't thought of separating the file though. So now I guess we have something like:
hello.en.md
- Hello, world!
hello.zh_CN.md
- 你好,世界!
hello.md
- { _hello }
po/en.po
- hello "Hello, world!"
po/zh_CN.po
- hello "你好,世界!"
@Keats: I much appreciated the RFC for i18n support in Gutenberg! It seems well-designed, and where the inspiration came from seems well-proven. :)
There is no tool/library for i18n in pure Rust as far as I know though, there's a couple of gettext crate but nothing really good apparently. The shared approach is interesting but then end users have to deal with gettext translations manually or upload them to some services like Transifex and it's not super user friendly (still need a way to deal with translations in templates though).
I would really like to contribute, especially on this issue. Do you think you could guide me somehow? I'm a beginner in Rust.
The problem is we first need to come up with a design
Challenges / Requirements
Design