Supporting i18n in Discourse

(Kuba) #1

I’d like to start a discussion about supporting localizations in Discourse. Currently Discourse has a few (almost) complete contributed translations. However, the current codebase does not support switching to another locale and has a few places that are hard-coded to use the “en” locale.

Server-side (Ruby code) is fine, and setting config.i18n.locale = :whatever is enough, but it has no effect on the JavaScript code. The source of the problem lies here:

But it’s not clear to me how to support proper i18n to the JS side of Discourse with respect to Rails’ asset pipeline. I would really like to help with implementing this, but I am mostly a Rails noob, and it seems to me that there is no easy solution. Having a config-dependent asset brings a lot of trouble. Exporting all the locales in a JS file currently generates a filesize of a few hundred kB, but can easily get into many megabytes when we have a lot of localizations.

Do you have some hints for implementing proper l10n to the JavaScript side? I recently added the “pseudo” locale into the repository, which seems like a good tool to debug/develop this.

Comrades let's join our efforts on ukrainian and russian translations
(Robin Ward) #2

Hi! Thanks for the interest in this. As you’ve noticed we never fully got around to allowing for changing locales in the codebase. It wasn’t an issue previously because we only had one locale but now that we have a few to play with we have fallen behind.

It is something that is on my list for this week to implement if you can wait a couple of days, but otherwise the general idea is:

  • Make sure the asset pipeline spits out translations for all locales into separate files (en.js, fr.js, etc.) I believe this might be baked into the application bundle right now - we should probably separate that.
  • In application.erb, include the asset for the current locale.
  • Add a site_setting for choosing the locale for a given site

(Julien Gourdon) #3

Shouldn’t this be defined by the user to override the site setting?

(Robin Ward) #4

I am curious about this - at first that was my inclination too but on our team call it was suggested that it would be odd for people to set the site to say french when the primary language of correspondance on the forum is english.

Honestly I don’t have much experience with people setting languages - would people do that? Set to another language than the base forum itself?

(Julien Gourdon) #5

Actually a good question.
As a French speaker, fluent in English, I often end-up on forums that does not speak French. I would not mind having the whole interface in my primary language.
I can also imagine whole discourse forums where the purpose is to talk about languages, or foreign trips, etc… where different sections/categories would even have different languages (used in the discussions), so every person can have a different interface.

(Alexander) #6

And the other way around — students of a language foreign to them may want to get used to interacting with user experience in the language they’re trying to learn.

(Or am I weird that way?)

(Philip James) #7

You’re not weird. I think language preference should be a choice of the user.

(Jeff Atwood) #8

Maybe eventually, but for now it is a forum level setting.

I am curious about people who go to and wish to change the amazon UI language to French. That seems awfully unrealistic to me.

(Kuba) #9

For me, it makes no sense to let users choose language of the forum. Mostly because the forum is all about the content and the content is not translatable.

(Kuba) #10

Can this be done without having separate en.js.erb, fr.js.erb, etc. files?

(Robin Ward) #11

It would probably be easier if anything to include all the translations in one big file. But that seems like a lot to transfer doesn’t it?

(Jeff Atwood) #12

Why would all the language assets be transferred? Wouldn’t just the language files matching the current forum language need to be transferred?

(Régis Hanol) #13

I tend to agree with @codinghorror. Even though it may seem easier on the developer side, it goes against the idea of transmitting only what’s necessary over the wire.

(Philip James) #14

I guess it depends on expectations. If the site has any sort of local content (like events, special deals, etc) people may want that local content, but presented to them in their native language (which may not be the language of the locale). I’ll agree it makes less sense for a forum, because the onus shouldn’t be on the software developer or even the forum maintainer to translate every post.

Helping give access to those whose primary language is not the language of the forum maintainers seems more like thoughtful design than a requirement. That also may be influenced by my $dayjob, where we want to make our site as accessible as possible, despite allowing people to create content in their native language.

(Kuba) #15

@eviltrout: I submitted first attempt to serve correct localized js files as rails pipeline assets by kubamracek · Pull Request #278 · discourse/discourse · GitHub, can you take a look at it?

(Julien Gourdon) #16

The content itself may be in different languages.
Nevertheless, I understand your and @codinghorror’s point. If the same content can be accessed through different front-end (let’s say,,…) then the localization can remain a site setting and not a user one. So users can access the content through whatever gate pleases them.

(Robin Ward) #17

I’ve deployed support for setting a locale via SiteSetting. I’d like to give a huge thanks to @kuba for giving me a head start. We don’t have a demo site to show it off, but I promise it works if you go into the admin section, change the locale setting and then refresh your page.

(Jeff Atwood) #18

We can probably write a blog post about this to solicit translations (and mention issues like date formatting, string size, etc) next week. I don’t feel we need a demo site for this.

(Régis Hanol) #19

i18n is quite hard to get it right.

As an example, here’s how Twitter is doing it: Rails Conf 2012 i18n on Rails: A Twitter Approach by Cameron Dutro

What needs to be considered:

  • dates / times
  • numbers
  • sorting
  • URLs
  • currencies
  • language names
  • countries
  • units of measure
  • character encodings
  • captcha
  • pluralization
  • tokenization
  • stemming
  • addresses
  • phone numbers
  • cultural cues
  • abbreviations
  • text direction
  • colors

(Kuba) #20

How about localizing strings in app/assets/javascripts/external, namely Markdown.Editor.js (the implementation of the message composer)? There is still quite a few hardcoded English strings and I would like to work on this. What is the best approach?

Since it is an external library, is it OK to make Discourse-specific modifications? This would probably be problematic with updating the library.