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

Translations #13

Closed
Keats opened this Issue Mar 25, 2017 · 13 comments

Comments

Projects
None yet
6 participants
@Keats
Copy link
Collaborator

Keats commented Mar 25, 2017

See how other tools like Hugo handle it.

@bingen13

This comment has been minimized.

Copy link

bingen13 commented Mar 25, 2017

Pelican has a lang attribute on the frontmatter of the posts. Posts which are translations of each other have the same slug. When presenting a post, the translations are offered (both on the category/tag/main view and when presenting the post by itself). The post presented by default is the one on the same language as the blog. Not sure what the resolution would be if none of the available languages is that one.

@Keats Keats added Feedback wanted and removed question labels Mar 25, 2017

@Keats

This comment has been minimized.

Copy link
Collaborator Author

Keats commented Mar 25, 2017

Something that would be needed when i18n is added is a i18n filter in Tera that would pull a string from various (yaml?) file in templates like Hugo does, it's not only the content that needs translations.

@severen

This comment has been minimized.

Copy link

severen commented Mar 25, 2017

See also the alternatives system that Lektor employs, which I use on my own website.

EDIT: My website is currently down due to renovations in my home rendering my server inactive, so if you want to see what the site is like live you'll have to clone the repo and build it yourself. If I get the time I'll set up a temporary GitHub pages mirror, but right now I don't have the time.

@sebasmagri

This comment has been minimized.

Copy link

sebasmagri commented Mar 25, 2017

From mdBook: rust-lang-nursery/mdBook#5

@Keats Keats added the help wanted label May 23, 2017

@Keats

This comment has been minimized.

Copy link
Collaborator Author

Keats commented May 23, 2017

I'm almost done with 0.0.6 and I think i18n will be the focus for 0.0.7 so it is time to start thinking about the design!
I've never used i18n on static site engine though so I don't think i'm the best person to design that but I can try given enough sources.
Do any of you know of open-source sites using i18n like @SShrike site? I like the Lektor approach at a glance but it looks like it wouldn't scale past a few languages, too much clutter.

My current thoughts were that any page that needs i18n needs to be in its folder in content, like pages with assets (https://github.com/Keats/gutenberg/tree/master/test_site/content/posts/with-assets). Default language is index.md and users can add no.md, fr.md etc that will get picked up automatically.
That means we need to change the internal linking to take into account the language somehow.

One issue is the _index.md for the sections, I can't figure out how to make those i18n friendly

Any obvious issues with the idea above, other than the _index.md?

@Keats Keats modified the milestone: 0.0.7 May 24, 2017

@Keats

This comment has been minimized.

Copy link
Collaborator Author

Keats commented May 31, 2017

(this is on hold until there is more feedback from people actually using/wanting i18n)

@Keats Keats removed this from the 0.0.7 milestone May 31, 2017

@batisteo

This comment has been minimized.

Copy link
Contributor

batisteo commented May 31, 2017

As mentioned by @SShrike, Lektor has two ways of dealing translations:

  1. It’s called Alternatives and basically the locale is appended to the file name with a plus sign, like _index+fr.md.
  2. The second way is called Data Bag – think gettext – and it’s for reusing "components" in a translated page.

I don’t know why Armin used these names, but I like the solution with a suffix (prefix is fine too).

I also used and like Nikola, witch also use a suffix, with an underscore, no folder needed. See my site repo.

The non-obvious part of i18n is also the default language and URLs. Should https://mysite.com/page be https://mysite.com/en/page?

@Keats

This comment has been minimized.

Copy link
Collaborator Author

Keats commented Jun 1, 2017

Thanks @batisteo !
The default content should be without a language code imo so https://mysite.com/page.
I can't find a huge static site using i18n so maybe my concerns with having hundred of pages in 4+ languages is exaggerated. I'm leaning towards the name+lang.md approach now.

An example of a Hugo multi-lingual site: https://github.com/scholarsportal/historical-topos/tree/master/content

@zoosky

This comment has been minimized.

@batisteo

This comment has been minimized.

Copy link
Contributor

batisteo commented Aug 16, 2017

[i18n] isn't a feature I need, I would rather have someone else doing it, once there is consensus on the implementation
@Keats on vincent.is

So, 1 we have to find a consensus, and 2 somebody has to do it.

I’ll try to work on it, but I'm an average Web (django) developer and have no clue where to begin.

Content

I would go for the Hugo and Nikola approch, which is page-name.fr.md with a fallback to the default language if the language extension is missing.

We might want to support locale names with the country like fr_CA or pt_BR.

These files are located in the content folder, next to the other files, with the matching name.

Translations

It would be nice to have gettext-like functionality.

Translated strings would be in the translations folder at the root of the project. Names like i18n or locale are ok but seem less userfriendly than the former.

About the format, I see 2 paths:

  1. gettext which is standard, but doesn’t have a first class support in Rust (inactive or experimental gettext, gettext-rs and crowbook-intl)
  2. TOML-based which could be userfriendly, but NIH.

In both case, we would need an implementation of {% trans "" %} in Tera.

@Keats

This comment has been minimized.

Copy link
Collaborator Author

Keats commented Aug 17, 2017

Thanks a lot for that!

I think the first step is to define exactly how everything will work, like the Rust RFCs so a bit more detailed than your post. A few points:

  • sections (index.md) can have content too
  • how to handle internal links and the get_url/get_page global fn (default to the current language being rendered unless it is a direct link like ./mypage.fr.md I guess?)
  • how to generate the url for a language: base_url/lang/ except for the default one that stays base_url?

For i18n, I'm wondering whether having it config.toml in a languages map would work so as TOML. As you mention, I don't think there's any good i18n library right now and I expect the number of translations to be relatively small as it will be just UI. This is basically what Hugo does in your link: https://gohugo.io/content-management/multilingual/#configure-languages and https://github.com/scholarsportal/historical-topos/blob/master/config.toml for a real example. Note that Hugo also has a i18n folder with yaml in it which makes me a bit confused as to why there 2 places to define translations

We can add global function in Gutenberg without having to touch Tera so we could have {% trans(key="", lang=lang) %}. This means adding the current language to the context of every page as well.

Regarding the implementation, it shouldn't be too hard and I can help you navigate the code when you get started.

Something I'd really like to see is some big static sites with i18n (could be jekyll, hugo, pelican, anything) to see how they manage it and if they have to do some hacks to do what they want, which would highlight some missing features.

@Keats

This comment has been minimized.

Copy link
Collaborator Author

Keats commented Aug 21, 2017

See #111 for the RFC

@Keats

This comment has been minimized.

Copy link
Collaborator Author

Keats commented Sep 14, 2017

Closing in favour of the RFC

@Keats Keats closed this Sep 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.