Edgewall Software
Modify

Opened 9 years ago

Last modified 4 years ago

#7417 assigned task

Translation of Trac to English [en_GB]

Reported by: dave@… Owned by: Mikael Relbe
Priority: normal Milestone: translations
Component: i18n Version:
Severity: normal Keywords: l10n english en_gb
Cc:
Release Notes:
API Changes:

Description (last modified by Jeroen Ruigrok van der Werven)

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

Attachments (3)

en_GB.messages.po (92.6 KB ) - added by dave@… 9 years ago.
en_GB translation
messages.po (163.5 KB ) - added by Mikael Relbe 8 years ago.
For Trac 0.12dev-r9573, 100%, no fuzziness
messages.2.po (163.5 KB ) - added by Mikael Relbe 8 years ago.
For Trac 0.12dev-r9579, 100%, no fuzziness

Download all attachments as: .zip

Change History (24)

Changed 9 years ago by dave@…

Attachment: en_GB.messages.po added

en_GB translation

comment:1 Changed 9 years ago by osimons

Milestone: 0.12
Owner: set to Jeroen Ruigrok van der Werven

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

comment:2 Changed 9 years ago by Jeroen Ruigrok van der Werven

Status: newassigned

comment:3 Changed 9 years ago by Jeroen Ruigrok van der Werven

Committed in r7514. Thanks!

comment:4 Changed 9 years ago by Jeroen Ruigrok van der Werven

Description: modified (diff)
Keywords: l10n english en_gb added
Priority: lownormal
Summary: Trac doesn't have British English (en_GB) translationTranslation of Trac to English [en_GB]

Changed the summary and description to match the rest.

comment:5 Changed 9 years ago by Christian Boos

Type: enhancementtask

comment:6 Changed 8 years ago by Jeroen Ruigrok van der Werven

Owner: Jeroen Ruigrok van der Werven deleted
Status: assignednew

comment:7 Changed 8 years ago by Christian Boos

Milestone: 0.12translations

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

At the very least, its 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.

Last edited 8 years ago by Christian Boos (previous) (diff)

comment:8 Changed 8 years ago by 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?

comment:9 in reply to:  8 ; Changed 8 years ago by 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.

comment:10 in reply to:  9 Changed 8 years ago by 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.

Changed 8 years ago by Mikael Relbe

Attachment: messages.po added

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

comment:11 Changed 8 years ago by Mikael Relbe

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

comment:12 Changed 8 years ago by 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.

comment:13 in reply to:  12 Changed 8 years ago by 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 :)

Last edited 8 years ago by Mikael Relbe (previous) (diff)

comment:14 in reply to:  12 ; Changed 8 years ago by 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 ;-)

comment:15 in reply to:  14 ; Changed 8 years ago by 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?

comment:16 Changed 8 years ago by Christian Boos

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

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

Changed 8 years ago by Mikael Relbe

Attachment: messages.2.po added

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

comment:17 Changed 8 years ago by 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…

comment:18 Changed 8 years ago by Christian Boos

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

comment:19 Changed 8 years ago by Mikael Relbe

messages.2.po committed in [9580].

comment:20 in reply to:  15 Changed 8 years ago by 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.

Last edited 8 years ago by Mikael Relbe (previous) (diff)

comment:21 Changed 8 years ago by Mikael Relbe

Owner: set to Mikael Relbe
Status: newassigned

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).

Modify Ticket

Change Properties
Set your email in Preferences
Action
as assigned The owner will remain Mikael Relbe.
The ticket will be disowned.
as The resolution will be set.
to The owner will be changed from Mikael Relbe to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .

 
Note: See TracTickets for help on using tickets.