Find a fair, but straightforward url structure for english and spanish curricula

[rachelmyers]

People are translating the RailsBridge curriculum. Which is amazing: When it's deployed, the curriculum will be more accessible to over 400 Million native Spanish speakers! :boom:

Right now, the fork nests the Spanish curriculum inside an /es folder, and following that current trajectory, the Spanish version of the Intro to Rails curriculum will eventually have the url railsbridge.org/es/intro-to-rails/. English speakers, meanwhile, will be the default: railsbridge.org/intro-to-rails/.

That seems unfair to me. English speakers always get the defaults. Maybe we can think of something better.

My first thought is to nest our English curriculum in /en, sorailsbridge.org/intro-to-rails/ becomes railsbridge.org/en/intro-to-rails/. (Maybe we set up permanent redirects for railsbridge.org/intro-to-rails/ to the English version, or maybe it's a "choose your language" page.)

I'd love to hear other solutions! :globe_with_meridians:

[lilliealbert]

Generally feeling :-1: about adding another directory level to the URLs. I'm not excited about the idea of having making the URLs less sayable. I'm also interested in knowing how often the spanish language version gets used. If it's once or twice a year, versus 20+ times a year for the english language curriculum, perhaps the anglocentrism is justified, despite being unfair.

It sounds like removing a default is a complicating gesture that doesn't really add anything to the app, other than people using the spanish curriculum feeling excited that the english speakers also have a subdirectory? Which they probably wouldn't know? Unless somehow they did?

I think separate apps would be quite sensical, and solves the problem. We could host a separate app at es.railsbridge.org perhaps.

[rachelmyers]

I'm also interested in knowing how often the spanish language version gets used.

Since it's still being created, it's not used as much as the English language curriculum. My impulse is to look at how often we expect it to be used in the future. :bowtie:

[lilliealbert]

Telling the future is much harder than looking at the past. :beers:

[rachelmyers]

We could try using the Accept Language Header to set the locale; that would keep the urls the same for everyone.

[alexch]

We can use Accept-Language but only as a hint; for various reasons [1] we'll always need a more explicit way to set the language. Some options:

• subdomain (es.docs.railsbridge.org) [e.g. en.wikipedia.org]
• subdir (docs.railsbridge.org/es/installfest) [e.g. nokia.com/en-us vs nokia.com/se-sv]
• query param (docs.railsbridge.org/installfest?l=es)
• cookie (probably a bad idea)
• probably other ways

Since the app is dynamic we can theoretically rewrite the HREFs to preserve the setting throughout internal links, so any of those first 3 are technically feasible, though the first two are probably easiest.

On the topic of special treatment for English, yeah, most sites have a default language and various contortions to accomodate alternates. so I agree with @lilliealbert .

[1]

• Many people don't or can't change their Accept-Language setting
• No way to specify a URL linking to the Spanish &c site
• Might be using a friend's computer with different settings
• Want to be able to debug and view side-by-side easily

[alexch]

See also #257

[alexch]

I've been messing around with the Spanish site and I have a proposal:

1. Reorganize the sites directory to have en and es subdirectories (and other locales in the future). Then in the code, sites_dir will make sense again. (Right now it's pretty messy, especially in the codificadas fork.)
2. Add the locale to the front of the URL path, with 301 redirects as needed to take existing links into the "en" hierarchy.
3. Use "es.railsbridge.org" as a redirecting hint only, same as with sites -- feed all docs URLs into the main "docs.railsbridge.org" app with the appropriate path.

To elaborate on 3 --

• http://docs.railsbridge.org would redir to http://docs.railsbridge.org/en/docs
• http://installfest.railsbridge.org would redir to http://docs.railsbridge.org/en/installfest
• http://es.railsbridge.org would redir to http://docs.railsbridge.org/es/docs
• http://es.installfest.railsbridge.org would redir to http://docs.railsbridge.org/es/installfest
• http://docs.railsbridge.org/installfest/get_a_sticker would redir to http://docs.railsbridge.org/en/installfest/get_a_sticker

and the "en" or "es" (or "fr_ca" or whatever) would be in the path forevermore.

(Another option would be to embed the locale in the subdomain but not in the path. This would make URLs shorter but would make development harder, since we'd have to figure out how to specify "I am running this app on localhost but in the Spanish locale" -- which isn't so bad but still weird.)

Thoughts? @tjgrathwell @nuclearsandwich @anymoto

[anymoto]

Alex, we're considering on create a new fork, since ours has a lot of patches due to the language issue. And yes, it is a mess. That's why we want to have a fresh new repo and just copy the content we've already translated.

Using subdirectories for the locales sounds good to me. I think that's a good way to support another languages besides en and es. And If the code changes are less complicated that way, I'd go for it.

[tjgrathwell]

Maybe I'm just being :us: anglocentric :us: but is there a strong argument against keeping locale information somewhere like local storage or the cookie? The worst problem would be if someone absolutely couldn't set the cookie value for some reason (some crazy browser? firewalls? paranoid security plugins?) and that locked them out of the spanish site, but I think you're going to need a reasonably open browser anyway for the scaffolded Rails site to actually function.

Since http://docs.railsbridge.org/installfest/ needs to still function for link compatibility purposes anyway, it doesn't seem great to also introduce a new form of link with the locale information stuck in the middle.

I'm imagining we could just have a little flag in the header that shows what the current locale is, changing it would go to the spanish version of that page (if available, otherwise just the root site page or root page). Maybe visiting es.railsbridge.org would force the locale to es.

[alexch]

is there a strong argument against keeping locale information somewhere like local storage or the cookie?

It makes my skin crawl: is that strong enough? :-)

In general local storage / cookies describe (semi-)permanent qualities of the user, but URLs describe qualities of the remote resource. Since there's nothing keeping users from being multilingual -- not to mention developers and translators -- it feels wrong to tie locale to a specific user. It also makes testing and coding weird. There's no problem looking at local info (e.g. cookies or Accept-Language) as a hint to which locale to start with (redirect to) or land on, but it feels wrong that, e.g. docs.railsbridge.org/rails-intermedio would work sometimes but would be a 404 error if I have the US cookie set.

There is ample precedent for specifying locale in path: e.g. nokia.com redirects to www.nokia.com/us-en/ and volvo.com redirects to www.volvo.vom/.../en-gb/...

http://docs.railsbridge.org/installfest/ needs to still function for link compatibility purposes anyway

Handled by a 301 Moved Permanently Redirect to http://docs.railsbridge.org/en/installfest/

I'm imagining we could just have a little flag in the header that shows what the current locale is, changing it would go to the spanish version of that page (if available, otherwise just the root site page or root page). Maybe visiting es.railsbridge.org would force the locale to es.

:es: :us: :fr: :it: :+1: for this UI.

We could be extra cool and optionally specify what this page's sister page is in language X, e.g.

intermediate-rails.step:
    translated :es, "rails-intermedio"

[alexch]

Alex, we're considering on create a new fork, since ours has a lot of patches due to the language issue. And yes, it is a mess. That's why we want to have a fresh new repo and just copy the content we've already translated.

But then you'd keep merging into the main fork, right?

I personally don't mind long, nested change histories. Digging into them can be very useful in tracking down bugs and workflow. And the codificadas fork is currently only a few pages long using git log --oneline --decorate --graph --all (my favorite way to look at git history). But if others prefer squashing them into a single commit then I'm ok with it.

[rachelmyers]

@alexch @anymoto Are you guys talking about separate things???

[tjgrathwell]

I personally don't mind long, nested change histories.

as contrast I would prefer not to have long, nested change histories

---

@alexch Those are all perfectly legit reasons to avoid using the cookie and have the locale information somewhere in the URL. Fair points all.

HOWEVER

I still would prefer keeping the locale information in the subdomain rather than as the first subdirectory, to wit:

http://docs.railsbridge.org/installfest - english (though in all locales the site should maybe have some little icon in the header so people can easily escape to other languages) http://en.railsbridge.org/installfest - also english http://es.railsbridge.org/installfest - spanish

Not sure what a good solution would be for localhost development, maybe an environment variable or just allowing a query param like ?l=es to always have the last word

[alexch]

Sounds like we've got an old-fashioned Mexican Standoff :-) (get it?)

Just kidding. I can go ahead with the filesystem refactoring and easily support either URL system. I'll have to change the git links -- can you think of anything else that will need to change?

I'd like to know what @anymoto @aromaron @sixviv (and other non-USA RailsBridgers) think about the different schemes.

One other issue -- to be properly compatible with our various existing sites, the locale-in-subdomain proposal would have to be es.docs.railsbridge.org (to allow es.www.railsbridge.org et al.) -- does that change the balance?

[tjgrathwell]

I'm not so sure about the need for es.www.railsbridge.org but I could survive es.docs.railsbridge.org if that's what truly feels most appropriate.

[ana-ci]

As a user, I think it's easier to identify versions and work with urls under this schema:

http://docs.railsbridge.org would redir to http://docs.railsbridge.org/en/docs http://installfest.railsbridge.org would redir to http://docs.railsbridge.org/en/installfest http://es.railsbridge.org would redir to http://docs.railsbridge.org/es/docs http://es.installfest.railsbridge.org would redir to http://docs.railsbridge.org/es/installfest http://docs.railsbridge.org/installfest/get_a_sticker would redir to http://docs.railsbridge.org/en/installfest/get_a_sticker

es.www.railsbridge.org seems a little bit weird for me.

[tjgrathwell]

I'm mostly on the side of trying to keep the URLs as short as possible to aid quick recall and minimize typing in a classroom setting. docs.railsbridge.org/installfest and es.railsbridge.org/installfest appeal to me on that level more than docs.railsbridge.org/en/installfest and docs.railsbridge.org/es/installfest, regardless of how many redirects might land you at the latter URLs.

As long as we have the locale information available in the domain, I think we should use it exclusively: adding the subdirectory just feels "computery" to me, it's making the file structure on disk too apparent.

But as I'm apparently the only one here with that position, maybe y'all should just go for it.

[alexch]

I'm OK with keeping English the default, so how about I go ahead with 1 (refactor the filesystem) and 3 (redirect from "es.rb.org/foo" to "docs.rb.org/es/foo" but "docs.rb.org/foo" is English) from my earlier proposal?

By the way, I must confess a faux pas: in this comment, I used a term that might be construed as derogatory to Mexicans. I didn't mean it as anything more than a joke (we're having a standoff about a Mexico-oriented feature) and I don't think any harm was done (confirmed by some private emails)... but still, I should have been more thoughtful, and I wanted to share my embarrassment and hopefully spare others from being on either side of any future misunderstandings. Cross-cultural references are all over our language(s), from English Muffins to Gypsy Cabs to Cafe Americano, and it's not always obvious ahead of time how the referenced culture will take it. 'Nuff said.

[anymoto]

Ok Alex, refactoring and redirecting in that way sounds good to us. :+1:

And thanks for the clarification regarding your comment. We don't think it was offensive and there's no problem at all :)

[alexch]

I've started work on this branch: https://github.com/alexch/railsbridge-docs/tree/locale

[alexch]

Okay, turns out Travis was right. Path-based switching was too difficult for Sinatra's and my tiny brains to figure out, so I went with subdomain and/or parameter and/or ENV var. Localhost development turns out to be really simple: launch the local server with SITE_LOCALE=es rake run.

[anymoto]

Thank you!! :tada:

Great job Alex :+1:

[alexch]

Ana, when I merged the locale branch into codificadas just now, I enabled syntax checking for the Spanish pages. It found several errors -- that is, Spanish pages that won't render. You're probably aware of them but if not, you can run rake after you sync and it will tell you. I'll paste the first one below so you know what I mean...

I'm about to deploy the heroku site... fingers crossed!

  in locale 'es'
    docs pages...
      renders docs.step
    frontend pages...
      renders _considera_lanzar_a_github.step
      renders agregar_archivos_iniciales.step
      renders agregar_mas_elementos.step
      renders CSS_basico.step
      renders estructura_HTML.step
      renders frontend.step
      renders hacer_columnas.step
      renders haz_una_pagina_web.step
      renders herramientas_de_desarrollo.step
      renders introduccion_a_HTML.step
      renders javascript_basico.step
/frontend/jquery: SyntaxError -
/Users/alex/Dropbox/dev/railsbridge-docs/sites/es/frontend/jquery.step:46:
syntax error, unexpected tSTRING_BEG, expecting keyword_do or '{' or '('
/Users/alex/Dropbox/dev/railsbridge-docs/sites/es/frontend/jquery.step:70:
syntax error, unexpected keyword_end, expecting end-of-input:
      renders jquery.step (FAILED - 1)
      renders jquery_vs_javascript.step
      renders recursos.step
    hola pages...
      renders hola.step
    installfest pages...
      renders _cambia_al_directorio_principal.step
      renders _instala_homebrew.step
      renders _instala_ruby.step
      renders _instala_rvm.step
      renders _instala_sublime_text_2_para_mac.step
      renders _instala_textmate.step
      renders colores_de_windows.step
      renders configura_git.step
      renders configura_la_terminal_de_windows.step
/installfest/consigue_un_sticker: NameError - undefined local variable or
method `cambia_al_directorio_principal' for #<Step:0x007fd892df1840>:
 /Users/alex/Dropbox/dev/railsbridge-docs/sites/es/installfest/consigue_un_sticker.step:47:in
`block (3 levels) in content'
/Users/alex/Dropbox/dev/railsbridge-docs/sites/es/installfest/consigue_un_sticker.step:46:in
`block (2 levels) in content'
 /Users/alex/Dropbox/dev/railsbridge-docs/sites/es/installfest/consigue_un_sticker.step:44:in
`block in content'
/Users/alex/Dropbox/dev/railsbridge-docs/sites/es/installfest/consigue_un_sticker.step:42:in
`content'
      renders consigue_un_sticker.step (FAILED - 2)

etc...

[alexch]

Heroku site works! Now since it reads the subdomain, you should not use railsbridge-es.herokuapp.com but instead use http://es.railsbridge.org/ e.g. http://es.railsbridge.org/installfest/configura_git

Locally launch it with SITE_LOCALE=es rake run

The default site in Spanish is still "hola" -- you can delete that site and rename "docs" to whatever you like, and change line 28 of app.rb .

On Wed, Feb 12, 2014 at 2:21 PM, Alex Chaffee alexch@gmail.com wrote:

Ana, when I merged the locale branch into codificadas just now, I enabled syntax checking for the Spanish pages. It found several errors -- that is, Spanish pages that won't render. You're probably aware of them but if not, you can run rake after you sync and it will tell you. I'll paste the first one below so you know what I mean...

I'm about to deploy the heroku site... fingers crossed!

  in locale 'es'
    docs pages...
      renders docs.step
    frontend pages...
      renders _considera_lanzar_a_github.step
      renders agregar_archivos_iniciales.step
      renders agregar_mas_elementos.step
      renders CSS_basico.step
      renders estructura_HTML.step
      renders frontend.step
      renders hacer_columnas.step
      renders haz_una_pagina_web.step
      renders herramientas_de_desarrollo.step
      renders introduccion_a_HTML.step
      renders javascript_basico.step
/frontend/jquery: SyntaxError -
/Users/alex/Dropbox/dev/railsbridge-docs/sites/es/frontend/jquery.step:46:
syntax error, unexpected tSTRING_BEG, expecting keyword_do or '{' or '('
/Users/alex/Dropbox/dev/railsbridge-docs/sites/es/frontend/jquery.step:70:
syntax error, unexpected keyword_end, expecting end-of-input:
      renders jquery.step (FAILED - 1)
      renders jquery_vs_javascript.step
      renders recursos.step
    hola pages...
      renders hola.step
    installfest pages...
      renders _cambia_al_directorio_principal.step
      renders _instala_homebrew.step
      renders _instala_ruby.step
      renders _instala_rvm.step
      renders _instala_sublime_text_2_para_mac.step
      renders _instala_textmate.step
      renders colores_de_windows.step
      renders configura_git.step
      renders configura_la_terminal_de_windows.step
/installfest/consigue_un_sticker: NameError - undefined local variable or
method `cambia_al_directorio_principal' for #<Step:0x007fd892df1840>:
/Users/alex/Dropbox/dev/railsbridge-docs/sites/es/installfest/consigue_un_sticker.step:47:in
`block (3 levels) in content'
/Users/alex/Dropbox/dev/railsbridge-docs/sites/es/installfest/consigue_un_sticker.step:46:in
`block (2 levels) in content'
/Users/alex/Dropbox/dev/railsbridge-docs/sites/es/installfest/consigue_un_sticker.step:44:in
`block in content'
/Users/alex/Dropbox/dev/railsbridge-docs/sites/es/installfest/consigue_un_sticker.step:42:in
`content'
      renders consigue_un_sticker.step (FAILED - 2)

etc...

Alex Chaffee - alex@stinky.com http://alexchaffee.com http://twitter.com/alexch

[alexch]

On Wed, Feb 12, 2014 at 2:21 PM, Alex Chaffee alexch@gmail.com wrote:

cambia_al_directorio_principal

by the way, "cambia_al_directorio_principal" is trying to call a method in step.rb but we should really take that out and use the new insert command instead to insert a shared partial called _cambia_al_directorio_principal.step -- see _consider_deploying_to_github.step for example.

[rachelmyers]

Thank you, @alexch! I'm really excited about this!

[anymoto]

Thanks Alex! we're looking at it.

This is exciting! :tada: