Plone's gettext approach and its impact on translation

Find below some feedback from Dwayne Bailey on Plone's gettext approach.
I've copied him again so he stays part of any discussion that might
follow.

-- 
Roché Compaan
Upfront Systems                   http://www.upfrontsystems.co.za

-------- Forwarded Message --------
From: Dwayne Bailey <[email protected]>
To: Roché Compaan <[email protected]>
Subject: Plone's gettext approach and its impact on translation
Date: Mon, 25 Oct 2010 11:40:41 +0200

Hi,

I'm doing some i18n work on a Plone application.  It is the very first
time that I look in detail at Plone localisation and I have some
concerns that I wanted to share with you.

Plone uses the msgid as key approach to Gettext instead of the msgid is
source text approach.

While this approach is not incorrect, the Gettext manual itself talks
about this approach.  The reality is that nobody really uses it in the
wild. So unless you are a Plone only translator this is a foreign
format.

The msgid is key approach usually creates issues in that the source text
is not defined, Plone works around the lack of source text by pushing
the source text into a developer comment.  But PO tools aren't really
designed to support this.  In most tools the comment will be placed in a
very different place to what translators are used to.  So you
essentially mess with a translators normal workflow.

Also, since the source text is now in a comment all of the support
infrastructure that a translator uses in their tools, Translation
Memory, Machine translation, terminology lookup, etc, are lost.  These
tools expect source text to be in the msgid so they are going to lookup
the key not the source text. The translator will not get any results
from these lookups. So essentially you put your translators at a
disadvantage, you make them work harder then they need to with the very
serious possibility of increasing translation error rates.

What makes it worse is that this key approach is not applied
consistently.  In cases where a key was not defined the text itself is
used. So now we need translators to be able to determine when they must
translate the key and when they must translated the comment!  This just
makes them slower as they need to interpret the text by looking at both
areas then decide what action to take.

From a translators perspective there are no advantages to the
monolingual Gettext approach.  None of our tools support this. If I told
a programmer to code in Notepad would they be happy?  No code
completion, no lookups, no syntax highlighting, nothing. It's
essentially what you are asking Plone localiser to do, "Just use a text
editor and drop your fancy PO editor".

So maybe I can pose some questions to the i18n developers.

1) Is there a plan to move to a more standard Gettext approach?
2) Are there plans to eliminate the confusing mix of key and source?
3) Has anyone written a fixplone script that converts Plone monolingual
PO files to a proper bilingual PO file?

Thanks for your help

-- 
Dwayne Bailey
Associate             Research Director        +27 12 460 1095 (w)
Translate.org.za      ANLoc                    +27 83 443 7114 (c)

Recent blog posts:
* Localizing Mac OS X strings files using open source PO editors
http://www.translate.org.za/blogs/dwayne/en/content/localizing-mac-os-x-strings-files-using-open-source-po-editors
* What's new in Virtaal 0.6.1
* Localisation: How we guess the target translation language in Virtaal

Firefox web browser in Afrikaans - http://af.www.mozilla.com/af/
African Network for Localisation (ANLoc) - http://africanlocalisation.net/






------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Plone-i18n mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plone-i18n