Re: wrong translations of gconf key values



On Thu, 2009-01-29 at 09:10 +0200, Dwayne Bailey wrote:
> On Wed, 2009-01-28 at 18:55 +0100, Andre Klapper wrote:
> 
> <snip>
> 
> > Example:
> > msgid "Possible values are \"always\", "\"bonded\"."
> > bad msgstr "Los valores posibles son: «siempre», «vinculados».
> > good msgstr "Los valores posibles son: «always» (siempre), «bonded» (vinculados)."
> 
> <snip>
> 
> > While I'm going to file bug reports for the rest of the evening I ask
> > you how to avoid this. :-)
> > 
> > To me it's obvious by looking at the filename of the string (ending with
> > ".schemas.in") that these values should not be translated, but to lots
> > of other translators it's not.
> > In http://bugzilla.gnome.org/show_bug.cgi?id=569457 aloriel proposes to
> > add a comment to each of these strings.
> > 
> > Other opinions/comments?
> 
> Nothing is ever obvious, especially to a new translator.
> 
> There are similar problems and some solutions that we found in the
> Mozilla localisation files. These allowed us to automate parts of the
> Translate Toolkit.
> 
> I'd like to propose that we adopt the Mozilla idea and extend it.  The
> idea is built around comments, but comments that are both human and
> machine readable.
> 
> Just dealing with the issue you discovered:
> 
> #. LOCALIZATION_NOTE: DONT_TRANSLATE_WORDS (always,bonded)
> msgid "Possible values are \"always\", "\"bonded\"."
> 
> The notes all start with 'LOCALIZATION_NOTE' and the type of note is
> denoted next, 'DONT_TRANSLATE_WORDS'.  Its verbose but it means that a
> person can read it but also a tool can be instructed to read it.  Thus a
> tool would simply need to detect the presence of 'always' and 'bonded'
> in the translation and fail if they are missing.
> 
> Adopting such a system required work by coders or maybe it should be
> localisers since we feel the pain.  It could be easily expanded to
> include things that capture setting e.g. OPTION (list,of,values), etc.
> 
> It would be easy to extend the Translate Toolkit to detect these and
> flag appropriate errors.  And also relatively easy to extend Virtaal
> (the translation editor we've developed) to catch those while editing.
> But any automated tool requires some structured information to back it
> up.  So we need to get some consensus on that first.

This bug http://bugs.locamotion.org/show_bug.cgi?id=781
is tracking adding this check to pofilter in the Translate Toolkit.  Its
dealing with the simpler case and none of the fancy stuff I dreamed of
above.  Hopefully it will be in v1.3 which has just gone into beta.

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

Recent blog posts:
* xclip - where have you been all of my life!
http://www.translate.org.za/blogs/dwayne/en/content/xclip-where-have-you-been-all-my-life
* Virtaal on Fedora
* Translate Toolkit on Fedora.  Status of Virtaal and Pootle

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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]