Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC Multi-language site support #392

Open
epage opened this issue Mar 7, 2018 · 8 comments
Open

RFC Multi-language site support #392

epage opened this issue Mar 7, 2018 · 8 comments
Labels
enhancement Improve the expected question Uncertainty is involved

Comments

@epage
Copy link
Member

epage commented Mar 7, 2018

Challenges / Requirements

Design

@epage epage added the enhancement Improve the expected label Mar 7, 2018
@epage epage mentioned this issue Mar 7, 2018
@pickfire
Copy link

pickfire commented Mar 7, 2018

GNU GetText style _ for i18n?

@ErichDonGubler
Copy link

@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.

@Keats
Copy link

Keats commented Mar 8, 2018

Note that I've written a RFC for i18n in Gutenberg: getzola/zola#111
Not implemented yet but is similar to the approach Hugo is using, which is quite good IMO

@pickfire
Copy link

pickfire commented Mar 8, 2018

@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:

split

  • hello.en.md - Hello, world!
  • hello.zh_CN.md - 你好,世界!

share

  • hello.md - { _hello }
  • po/en.po - hello "Hello, world!"
  • po/zh_CN.po - hello "你好,世界!"

@ErichDonGubler
Copy link

@Keats: I much appreciated the RFC for i18n support in Gutenberg! It seems well-designed, and where the inspiration came from seems well-proven. :)

@Keats
Copy link

Keats commented Mar 8, 2018

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).

@epage epage changed the title Multi-language support Multi-language site support Mar 12, 2018
@epage epage added the question Uncertainty is involved label Mar 19, 2018
@epage epage changed the title Multi-language site support RFC Multi-language site support Mar 19, 2018
@ail3ngrimaldi
Copy link

I would really like to contribute, especially on this issue. Do you think you could guide me somehow? I'm a beginner in Rust.

@epage
Copy link
Member Author

epage commented Jul 8, 2024

The problem is we first need to come up with a design

  • We'd need an understanding of the requirements. What do people expect out of this? What assumptions can be made?
  • It'd help to look at how other SSG's support multi-lingual sites (config fields, source layout, output layout) so we can learn from them. Even better to do a comparative analysis
  • With the above two, we need at least one design proposal and to iterate on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improve the expected question Uncertainty is involved
Projects
None yet
Development

No branches or pull requests

5 participants