Skip to content

/prev.rust-lang.org

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

Get started on internationalization/localization #296

Merged
merged 1 commit into from Jul 8, 2016

Conversation

Reviewers
No reviews
Assignees

@brson brson

Labels
None yet
Projects
None yet
Milestone
No milestone
9 participants
@steveklabnik @rust-highfive @sanmai-NL @brson @alilleybrinker @alexcrichton @aturon @huonw @nikomatsakis
@steveklabnik
Copy link
Member

steveklabnik commented Jan 28, 2016

This is a work in progress PR for my proposal of https://internals.rust-lang.org/t/translations-for-rust/3126

Right now, there's just one commit: moving everything from the top level into /en. I've also put in redirects for the existing pages, to go to the English versions for now.

More to come!

@rust-highfive rust-highfive assigned nikomatsakis Jan 28, 2016

@rust-highfive

This comment has been minimized.

Sign in to view
Copy link

rust-highfive commented Jan 28, 2016

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@steveklabnik steveklabnik assigned brson and unassigned nikomatsakis Jan 28, 2016

community.md Outdated
<head>
<meta http-equiv="refresh" content="0;/en/community.html" />
</head>
</html>

This comment has been minimized.

Sign in to view
Copy link
@huonw

huonw Jan 29, 2016

Member

Maybe this should be abstracted out into a layout, so making it handle the language redirects works properly, e.g. each file that needs to redirect is just

---
layout: redirect
---

with _layouts/redirect.html containing:

<html>
  <head>
    <meta http-equiv="refresh" content="0;/en/{{ page.url }}" />
  </head>
</html>

(Untested)

This comment has been minimized.

Sign in to view
Copy link
@huonw

huonw Jan 29, 2016

Member

Oh, it won't work with user_groups, so maybe the layout needs to be

<html>
  <head>
      <meta http-equiv="refresh" content="0;/en/{% if page.redirect_to %}{{ page.redirect_to }}{% else %}{{ page.url }}{% endif %}" />
  </head>
</html>

and then user_groups.md is

---
layout: redirect
redirect_to: user-groups.html
---

(The others are unchanged.)

This comment has been minimized.

Sign in to view
Copy link
@steveklabnik

steveklabnik Jan 29, 2016

Author Member

I like this idea.
@sanmai-NL

This comment has been minimized.

Sign in to view
Copy link
Contributor

sanmai-NL commented Feb 1, 2016

One thing that needs to be correct from the start: not to use en but to specify the language variety. @steveklabnik thinks the current material is meant to be in American English, so please encode that. This is important to prevent mixups of varieties in contributed documentation. https://en.wikipedia.org/wiki/Language_localisation#Language_tags_and_codes
@steveklabnik

This comment has been minimized.

Sign in to view
Copy link
Member Author

steveklabnik commented Feb 1, 2016

Ah yes, I was copying Ruby, but en-US would be better.
@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Feb 2, 2016

Is it really necessary to use en-US instead of en here? It's is more technically correct but: it will make the URLs uglier, and we don't need to ever add variations of the website for a single language, and probably won't.
@alilleybrinker

This comment has been minimized.

Sign in to view
Copy link
Contributor

alilleybrinker commented Feb 2, 2016

It may be sufficient to use the ISO 639-1 codes rather than IETF language tags. On the one hand, the IETF tags are more exact, on the other the ISO 639-1 codes are better for URLs and may provide enough information. There's the question of how many translations we expect the site to have, as well.
@steveklabnik

This comment has been minimized.

Sign in to view
Copy link
Member Author

steveklabnik commented Feb 2, 2016

We don't have to use en-US. It's just extra information, to signal that we're specifically using American English. I don't super super care, as I prefer the ergonomics of en, but the exact-ness of en-US.
@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Feb 2, 2016

It might be worth getting more input on the 'en' vs 'en-US' issue, though I imagine we can just make more redirects if we pick wrong.

This looks good to me with or without @huonw's suggested changes, though I agree factoring out the redirect seems better.
@sanmai-NL

This comment has been minimized.

Sign in to view
Copy link
Contributor

sanmai-NL commented Feb 2, 2016

  1. You never know for sure what language varieties translations will be provided for in the future. Just as with code, it's easier to simplify later than to add edge cases later.
  2. Whether the URL would be uglier is a matter of taste, thus it's subjective (unless someone has studied such usability aspects seriously?) and that makes it hazardous to assume some alternative URL is better. Many software projects, e.g. Mozilla's own Firefox, have en-US in their URL, even for end-user facing websites, e.g. https://www.mozilla.org/en-US/firefox/new/.
  3. The point I made earlier is most important though: it is not clear that en means American English and in fact I've seen British English mixed up with American English on the website (e.g., ‘finalise’). This will at some point cause duplicate work when someone contributes documentation written in the wrong variety.
  4. Believe it or not, such choices may aggravate non-American English speakers, when it appears that American is assumed to be the only English. Such things can be taken way too seriously and that will hurt inclusiveness. For instance, the R language has both licence() and license() and advertizes both on startup of the REPL. I suppose some fighting went on to make it so ... Seems entirely unnecessary, but alas.
@steveklabnik

This comment has been minimized.

Sign in to view
Copy link
Member Author

steveklabnik commented Feb 2, 2016

such choices may aggravate non-American English speakers, when it appears that American is assumed to be the only English.

Oh I'd believe it.

@steveklabnik steveklabnik force-pushed the steveklabnik:translate branch from 6c57f76 to e104d85 Mar 1, 2016

@steveklabnik

This comment has been minimized.

Sign in to view
Copy link
Member Author

steveklabnik commented Mar 1, 2016

Getting back to this, I've updated with @huonw 's suggestions, I think it's a lot cleaner. I've also done the en-US, as I think that I'm feeling like that's the right call, but we should discuss it.

There's one other little thing I've noticed while playing with this: the main header links link to /documentation.html, for example, which goes back to the root, which gets redirected. We may want to make these relative rather than absolute links?

@steveklabnik steveklabnik referenced this pull request Mar 30, 2016

Merged

Flesh out the irc channels #330

@steveklabnik

This comment has been minimized.

Sign in to view
Copy link
Member Author

steveklabnik commented Mar 30, 2016

/cc @rust-lang/core, wrt both en vs en-US and the relative vs absolute link issue
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Mar 31, 2016

I don't have much of an opinion on en vs en-US. I like en better because it looks nicer, but if en-US is "more correct" then it's more correct. I'd also recommend relative links wherever possible because you wouldn't necessarily want to click a link on the German translation and get redirected to the English translation by accident.
@aturon

This comment has been minimized.

Sign in to view
Copy link
Member

aturon commented Mar 31, 2016

+1 on en-us, that's definitely best practice here.

@steveklabnik steveklabnik force-pushed the steveklabnik:translate branch from e104d85 to b1b8942 Jul 7, 2016

@steveklabnik

This comment has been minimized.

Sign in to view
Copy link
Member Author

steveklabnik commented Jul 7, 2016

Whew!

I just completely re-did this PR, so that it's current with all changes to the website since back in January. I have set it up to do the en-US bit, as well as fixed the links in the headers so that they redirect to the same language, rather than back to the root URLs.

We should merge this sometime reasonably soon so it doesn't bitrot again.
@steveklabnik

This comment has been minimized.

Sign in to view
Copy link
Member Author

steveklabnik commented Jul 7, 2016

#433 has now been merged, so this is already out of date :9
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Jul 8, 2016

cc @brson, think we're ready to pull the trigger on this?
@steveklabnik

This comment has been minimized.

Sign in to view
Copy link
Member Author

steveklabnik commented Jul 8, 2016

Yeah, if you let me know when we're ready, I can make the final sync update and merge.
@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Jul 8, 2016

Yes, do it.
@steveklabnik
Begin the process of i18n. 
This commit introduces the structure needed to translate the website
into multiple languages. Specifically:

* A new layout, redirect, is introduced
* Existing pages are updated to use this layout so links don't break
* Existing content is moved onder en-US
* Header is updated to use relative rather than absolute links

The redirect layout only has one option, en-US, currently, but is
written in a way that will facilitate other languages easily in the
future. Thanks to ruby-lang.org, from which this code was adapted.
Loading status checks…
a8884c5

@steveklabnik steveklabnik force-pushed the steveklabnik:translate branch from b1b8942 to a8884c5 Jul 8, 2016

@steveklabnik steveklabnik merged commit 6e05503 into rust-lang:master Jul 8, 2016
1 check passed

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@steveklabnik steveklabnik deleted the steveklabnik:translate branch Jul 8, 2016

@steveklabnik

This comment has been minimized.

Sign in to view
Copy link
Member Author

steveklabnik commented Jul 8, 2016

🎊

steveklabnik added a commit to steveklabnik/rust-www that referenced this pull request Jul 11, 2016

@steveklabnik
Fix the friends page for i18n 
This got missed somehow in rust-lang#296

Fixes rust-lang#437
6660e9b

@steveklabnik steveklabnik referenced this pull request Jul 11, 2016

Merged

Fix the friends page for i18n #438

@alilleybrinker alilleybrinker referenced this pull request Dec 31, 2016

Closed

Fix French translation. #659

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.