Fixed #12641 : cannot add translations to eng-GB

[masev]

i18n skip translations for eng-GB and it's hardcoded in kernel. This is a problem when dealing with a lot of languages as if there is change in an english string we need to update every TS files.
Furthermore, in the idea of keeping presentation and content separated labels should not be the content more a placeholder like {'confirm_registration_text'|i18n('my_namespace')}

[andrerom]

As long as eng-GB is the native language and there are no translation files for it I will have to vote -1
This is a major change to how the ts system works and if we do such a thing it should be native, not an after thought.

[glye]

Having eng-GB translateable might be ok. Using placeholders instead of real English strings is a problem. First, it makes template development and debugging harder. Second, it means the translation tools won't work as they should (ezlupdate and Linguist). We would have to replace those tools before we could make such a change.

[masev]

The translations tools will work the same for example it will produce for eng-GB :

confirm_registration_text Thank you for your registration.

Anyway this modification doesn't force people to do that but it removes the hardcoded test that block people for doing that. All translations files can be kept as they are.

[glye]

Masev, it won't work the same:

1. How does the translator know that "confirm_registration_text" should be translated into the e.g. French equivalent of "Thank you for your registration."? He will have to keep two Linguist windows open and switch back and forth between them, which is cumbersome.
2. It breaks the Linguist feature that suggests translations based on what you have translated before, since the original language won't be available in the file.
3. It breaks the Linguist feature which checks that punctuation is the same in source and translation.
   There might be other problems too, for all I know. (I understand that this patch doesn't enforce placeholders.)

[masev]

Ok I understand it will break some Linguist feature. The impact is then larger than I thought.
Anyway, the problem when having a change in a source string is annoying. Maybe the hardcoded test should be, as I proposed, kept customizable and we could add a comment to explain the impact a such a change... What do you think ?

[dpobel]

This is a very common issue in non-english integrators world because it's quite common to work on a site without the definitive english texts but obviously you already have the other(s) translation(s) and in this case it's a real mess to manage :-/ I know a lots of projects where the ezi18n operator is hacked or a new operator is defined without this hardcoded condition as a workaround.

And btw, the fix keeps the current behavior but allows to bypass the limitation, it's fine for me.

[glye]

I understand the need, but agree with andrerom that we should also distribute eng-GB translation files if we are going to change this. They must be generated and maintained. (And of course the default setting must be: no change.)

[dpobel]

I don't see why we should create a eng-GB file if we still write our templates in eng-GB ?

[masev]

Hello guys, any news about this pull request ? What's the final decision :)

[bdunogier]

As long as ezlupdate still generates original files (I don't see why it wouldn't), and as long as what currently works still works, I don't see why we wouldn't support this.

The only drawback is that unmodified templates will have a wrong source language, but I take it this would only be used for the frontoffice, and even origin templates could still be translated, in any case...

Since we already support non eng-GB as the base Content language, we should support non eng-GB as the base static language.

[tzi]

Hi !
I'm giving you some feedback on this pull request.
My teammates are not all english speaker. So It's difficult for us to write a right label for the i18n.
Usually, the translator will arrive after the website integration done. So we have to change every label directly in the templates.

I think our process is contrary to the purpose of the i18n.

I have wrote a blog post on "How hack eZ Publish to use french language in i18n labels" (http://goo.gl/wXie1) Because it's really a source of problems.

See you.

[simonjenn]

+1 for this change, this behaviour is really annoying.

When the mother tongue of the website is French, and that translators work primarily from French to other languages, this will be more easy for them.
Until that changes, I used the solution described here: http://serwatka.net/blog/overriding_translations_in_ez_publish_4_1_and_higher

Cheers

[emodric]

+1 for this change, I don't see a problem with it since it's turned off by default. There's no need to add and maintain any new translation files.

If someone wants to turn on this feature, it would be his/hers sole responsibility to add eng-GB/translation.ts

[rey0bs]

Hi,
This pull request is very usefull for all non-english developer, because in most case development work comes before translating work.
So, i18n operator displays the translate key by default if there is no traduction. You can use english text as a placeholder, as well as before, even if the new system is enabled...

[Tumulte]

I must say it's a long time wanted feature. Every language should have the same behaviour in i18n.
Actually, it's quite frequent that a client decide to add an English access AFTER the site is made in the client's mother tongue. Either they didn't plane it at first or they take care of the translations in the very end of the process.
Moreover we just can't guess what the English words will be, since it's often very specific words and not casual English. Even if it's casual English, choose a word, the client will want another one...

Anyhow, for every non-English developers (and we are quite a lot) this feature is a complete "must-pull"

[gmarty]

+1

I had to update ~15 translations files recently :-s

[andrerom]

Lets close the voting please, it is obvious that many people want this.
IMO would like to see another approach on the underlying issue, but I guess this is better then nothing.

Patch needs to be updated against master @masev.

[masev]

Hi @andrerom, just made a git merge upstream/master but it says nothing to commit ... Can you help me on this, what should I do to update the branch ?
Thanks !

[andrerom]

"nothing to commit "
That is normal after completing a merge, but there is something to push right?
If you do "git st" you should see the status and with "git log -1" you should see that last commit is a merge?

[masev]

Oh ok. Thank you André, I think I got it right now :)

[emodric]

There's one more line that needs to be changed for this to work. /kernel/common/ezpi18n.php - line 98

[masev]

You're right Edi, it's fixed.

[Ricozor]

+1

it should be very use full

[nfrp]

Thanks @masev for the impulse, very useful feature for international integrators.
Do you guys see other required code modifications before we move-on to the "functional documentation stub" phase ?