Translation of Trac to English [en_GB]

[dave@…]

This ticket should be used to coordinate the translation to English (en_GB). See also source:trunk/trac/locale/en_GB/LC_MESSAGES/messages.po​

[dave@…]

en_GB translation

[osimons]

Thanks! Assigning the task to our i18n department :-)

[Jeroen Ruigrok van der Werven]

Committed in r7514. Thanks!

[Jeroen Ruigrok van der Werven]

Changed the summary and description to match the rest.

[Christian Boos]

I'm very doubtful if there's any utility for this translation…

At the very least, it's current content is very buggy. Only the sentences that differ from American English should be translated, the others should be left empty.

And I didn't see in the current en_GB/../messages.po file any translation where there was an actual difference, except for obvious fuzzy induced errors.

Proposing for deletion.

[dave@…]

Us English people get annoyed with mispelt words being use as a default. In essence the differences are to do with use of -ize (en_GB: -ise), license (en_GB as a noun: licence, as a verb: license), color (en_GB: color) and a few other things over word order, comma usage and appropriate verb use (e.g. en_GB tends not to turn nouns into verbs as much).

A separate en_GB translation is usually available in most large pieces of software (e.g. Windows, Gnome, KDE, mozilla, OS X)

Deleting this because it doesn't have enough differences is a bit strange; would you merge the pt and pt_BR strands?

[Christian Boos]

Replying to dave@…:

Us English people get annoyed with mispelt words being use as a default. In essence the differences are to do with use of -ize (en_GB: -ise), license (en_GB as a noun: licence, as a verb: license), color (en_GB: color) and a few other things over word order, comma usage and appropriate verb use (e.g. en_GB tends not to turn nouns into verbs as much).

… mispelt words, right ;-) Ok, I knew there were differences between the two variants, but my point was that it wasn't obvious to discover those in the current en_GB translation, as most translations were identical. Now that you pointed me to the ize/ise, license/license, color/colour differences, I see that they are indeed addressed. I think that future versions should only have non-empty msgstr when they differ from the msgid.

[Christian Boos]

… future versions should only have non-empty msgstr when they differ from the msgid.

Please, someone should volunteer for this. Wrong translations are problematic to use due to ​#G378.

In this specific case of US to GB English "translation", we should only have something like 20 - 50 messages really needing to be translated, all the others should be left untranslated and non fuzzy.

[Mikael Relbe]

For Trac 0.12dev-r9573, 100%, no fuzziness

[Mikael Relbe]

I did a heavy, intellectual effort :) and finished this one off so that 0.12beta1 can be released.

[Remy Blank]

Thanks for picking this up. I was going to refer to comment:10 and repeat that only the messages that differ from en_US should be "translated", and that messages that are identical should be left empty. But I'm not sure anymore this is the right approach. How will we differentiate between a missing translation and an unneeded translation in the future (after catalog updates)? It would require scanning through all untranslated messages. Whereas if we translate all messages, even those that are identical, the new messages are easy to identify.

So I'd argue that Mikael's approach is more useful in the long run.

[Mikael Relbe]

Replying to rblank:

How will we differentiate between a missing translation and an unneeded translation in the future (after catalog updates)? It would require scanning through all untranslated messages. Whereas if we translate all messages, even those that are identical, the new messages are easy to identify.

Yes, I also arrived at the same conclusion when working with this file, and took a quick decision to "translate" it all for just that reason.

Thanks for the reply, now I feel less intellectually retarded than I did during the "translation" work — and that feels good :)

[Christian Boos]

Replying to rblank:

Thanks for picking this up. I was going to refer to comment:10 and repeat that only the messages that differ from en_US should be "translated", and that messages that are identical should be left empty. But I'm not sure anymore this is the right approach. How will we differentiate between a missing translation and an unneeded translation in the future (after catalog updates)?

With a diff?

So I'd argue that Mikael's approach is more useful in the long run.

We'll see ;-)

[Remy Blank]

Replying to cboos:

With a diff?

Sure, that does the trick, and would even work well for me, as I'm using a simple text editor for working on translations. I thought you guys were using specialized translation tools, and I assume those aren't diff-aware, so you first have to find the message with the diff, then find the corresponding message in the tool, then finally you can "translate" it.

I guess whatever works best for the translation maintainer is ok for me. Speaking of that, can you give Mikael commit access to the en_GB translation?

[Christian Boos]

messages.po​ committed in r9576, huge diff, beware…

As for commit access to this file, I'll give it to all translators.

[Mikael Relbe]

For Trac 0.12dev-r9579, 100%, no fuzziness

[Mikael Relbe]

messages.2.po​ added for last extraction, also GB'fied a couple of words

There are more work to do with this "translation" since EN-GB Does Not Write Headlines Like This as EN-US does…

[Christian Boos]

Mikael, you should be able to commit to trac/locale/en_GB by yourself now (same for other translators).

[Mikael Relbe]

messages.2.po​ committed in [9580].

[Mikael Relbe]

Replying to rblank:

I thought you guys were using specialized translation tools, and I assume those aren't diff-aware, so you first have to find the message with the diff, then find the corresponding message in the tool, then finally you can "translate" it.

I am gaining experience in using ​Poedit (available on all platforms), which I like alot, and these assumptions don't apply here, which I would like to point out.

When a .po file is opened after having been compiled, all changed and fuzzy translations are highlighted and brought to my attention. With a simple click I can jump to the source of the original text in the source code to study its context. Pressing a shortcut key (Alt-C on Windows) "translates" the currently selected message as a plain copy of it — perfect for translating en-GB :) There is also a multi-bookmark feature which allows you to jump around and quickly return to a desired location. The search function can be targeted to original messages or translations only, or both. Very handy for making consistent translations of expressions and phrases.

There are a couple of drawbacks (applies to Poedit v1.4.6):

1. Translated strings are stored as one-liners; the .po file should therefore not be committed unless re-compiled. This is really not an obstacle since a translator should test the work before committing it, which involves re-compiling the .po file anyway. (But to be honest, I have myself already failed once with this, and it will happen again for sure :)
2. Messages that becomes unused after a compilation are removed when the file is opened by Poedit. The solution to this, of course, is to start a translation session by making two local copies of "message.po", before and after the first compilation. The second copy will contain all removed phrases at its end.

I think Poedit is a time saver compared to using an ordinary text editor. Highly recommended.

[Mikael Relbe]

Since I am the only one contributing to this, I take ownership of this ticket at the moment as an indication that this matter is being handled. Anyone, especially a native en-GB speaking person, who would like to step in and take over are very welcome to do so. Until then, I'll try to keep the en-GB translation updated (and hopefully in an acceptable shape).