Missing translation defaults to english


(Rafael Pereira) #1

Continuing the discussion from Translation issues:

As commented by @pyro240, it would make responses times slower and all those things but really, english should be there since the beggining. Showing just keys is not just user unfriendly, it makes the system totally unusable. If a string isn’t there, the UI simply doesn’t work. That happens in admin panel too. It’s simply horrible because it’s community dependant - not that I’m comlpaining, that’s fantastic, but since features keep coming, the community may not have time to translate in time for a release - which is ok too and giving the english string makes it still usable until it’s translated. Who else agree here?

Examples:




(Rafael Pereira) #2

Any thoughts into this? It’s really worrying :worried:
A lot of users can’t understand what is going on with the buttons, mainly some of the most important like Login:


(Jens Maier) #3

Doesn’t Rails provide fallbacks for I18n? It could be a GlobalSetting and disabled by default so there’d be no additional runtime overhead at all for the typical (english) use case.


(Rafael Pereira) #4

Yes. Something like

config.i18n.fallbacks =[:en]```
in production.rb would do the trick, I suppose. Gonna test and post it back.

EDIT: in environments/production.rb there is a line reading `config.i18n.fallbacks = true` so I believe it should be working already, no?

EDIT2: tried to put `I18n.default_locale = :en` in production.rb but no success still :worried: 

(elsdoerfer) #5

Horrible UI, given that all translations are incomplete. If there are performance concern, surely this can be fixed in the pre-processing steps.

It might also be case for “don’t invent your own i18n system” - this wouldn’t have happend with gettext to begin with.


(Rafael Pereira) #6

Is there a quick way to fix this? I can’t get new versions without noticing a lot of missing I18n texts all around. I am on the localization team but I can’t keep up all the time and the website suffers a lot from it. Recently: http://puu.sh/ab02x/86fd4441d3.png


(Sam Saffron) #7

We are too flooded with v1 work at the moment, we would need a community contribution to help with this if we want it this month.


(Rafael Pereira) #8

I’m willing to help, I just don’t know the details yet. If you have any tip I’d appreciate it. Should be just a check for keys but better yet if it could be cooked in precompile stage.


(Sam Saffron) #9

There are multiple approaches you can take, probably the simplest is, in production mode, amending the client side erb to generate the js file with a en fallback. Server side should be simple enough.


(William Di Luigi) #10

Hi, are there updates about this? :innocent:


(Michael - DiscourseHosting.com) #11

We found a pretty neat hack to quickly implement a fallback-missing-translation-to-english mechanism, leveraging the fact that a plugin can bring it’s own translations, but translations shipped with Discourse will prevail.

Say you want all missing dutch (NL) translations to fall back to English.

  • Create a new plugin (discourse-translationfallback)
  • Make a config/locales directory
  • Copy the original en language files shipped with Discourse into it but change the locale in the filename.

Copy config/locales/server.en.yml
to plugin/discourse-translationfallback/config/locales/server.nl.yml

Copy config/locales/client.en.yml
to plugin/discourse-translationfallback/config/locales/client.nl.yml

In client.nl.yml change the top key en: to nl:
(You don’t need to do this in server.nl.yml for some reason)

Precompile assets and restart Discourse, and presto!

If we have some time this week, we’ll make this a ‘real’ plugin, although I guess it wouldn’t be too difficult to implement this in a more native way.


(Kane York) #12

Make it into a block of instructions someone can paste into their app.yml. There’s no actual need for a plugin like this to have updates.


(Michael - DiscourseHosting.com) #13

I’m not sure I understand what you mean, the plugin would need updates if there are new language strings in a new Discourse release.

Pasting things into a file doesn’t sound very automation-friendly, although I do like the idea of having the plugin being generated automatically. Is there a hook where one can put code that is executed when a plugin is installed or updated ? (preferably something that’s working in an non-docker environment as well)


(Michael Downey) #14

Perhaps what @riking is saying is that it shouldn’t require a plugin to get English fallback defaults for things like:

IMHO even English would be better than trying to make sense of the code-based names & descriptions like that. :slight_smile:

(Yes, are users are seeing some things like this and wondering what it’s about.)


(Michael - DiscourseHosting.com) #15

Yes, I agree. It shouldn’t require a plugin, but apparently it does…
We’re getting a lot of complaints about this and I think it’s affecting Discourse multilingual adoption a lot right now.


(Rafael Pereira) #16

I’ve been saying it is affecting for some time. I agree it’s not an easy
solution but should be.

Interface and clean communication play a very important role to be a next
gen forum software and non-english speakers are feeling this can’t be
trusted right now, even not being a beta anymore. I feel sad about it =/


(Régis Hanol) #17

Translation fallback issues should be a thing of the past :ghost:


(Régis Hanol) #18