[Localization] Appel à traduction Créole Haï tien

[Jude Augusma]

I am wondering if we are implying to Jude and other translators that they should translate strings that do not need translation.  If so, shouldn't these strings be dropped from the lists?

I really think this is the case I am dealing with now. I think I am struggling with words and strings that do not have a translation and Creole does not have so many words like English.  If you guys can identify them and drop them from the lists, I believe it could be of some help.
Jude


----- Original Message ----
From: Chris Leonard <cjlhomeaddress at gmail.com>
To: localization at lists.laptop.org
Sent: Sunday, June 22, 2008 6:04:37 PM
Subject: Re: [Localization] Appel à traduction Créole Haï tien




On Sun, Jun 22, 2008 at 5:50 PM, Marvin Demuth <marvindemuth at sbcglobal.net> wrote:

At 04:01 PM 6/22/2008, "Chris Leonard" <cjlhomeaddress at gmail.com> wrote:


Some of those challenges will be based on coining new terms in a language that is perhaps not a primary language for technology development, the discussion of that topic alone will certainly be reproduced many times in many languages. 
I am wondering if we are implying to Jude and other translators that they should translate strings that do not need translation.  If so, shouldn't these strings be dropped from the lists?

This came to my mind when I read this recent comment by Ed Cherlin:


> attachmentOwnerChanged


This seems to be a piece of program code. If so, leave it as is unless

we translate the identifiers in the program someday.


> sourceConnected

> RandomConnector


Also identifier names.

Shouldn't identifiers be eliminated from the translation system?

Marvin Demuth
 
I wouldn't necesarily advocate localization efforts beyond the standards maintained by other localized software packages.  I would agree that code-internal variable names/identifiers may not necessarily require immediate localization to allow comprehension of source code function (even in English, many internal terms are obscure enough to be just placeholders without much human-readable semantic content), but I can't speak to those specific examples.  As Ed mentioned, at some point, a familiarity with the given activity/code and what strings are typically exposed to the average user is needed to make judgement calls on the depth of strings that should be localized and to give the proper context to translate their meaning. 
 
There will however be terms needed for "Start up" guides and the like (either hardware or software) that were neologisms (new words) in English not so long ago ("touchpad", "reboot", "motherboard", etc.) that may not already have cognate terms in various languages and require some careful creation of local neologisms.
 
What I was suggesting was: 
 
a) that the discussion and general resolution of those situations could sometimes be informative/applicable to more than a single language (trivial example: "boot" means "start" or "begin" in context of electricity, let's try a transliteration of "start power over again" for "reboot".   The point you raise about whether the gettext() of a given package has performed it's i18n job appropriately and yielded the right pootle strings is another example where error-correction by one group can benefit those who follow. 
 
b) That even if there were some procedural obstacles encountered in carving out a new project space on OLPC infrastructure (as opposed to a rapid provisioning of an off-OLPC mailing list), there are some potentially good reasons to expend the extra effort to work through those obstacles as a Constructionist learning opportunity for OLPC to get better at supporting such efforts.  This latter point is obviously something done for the long-term benefit of others,  a concept I think many of us embrace at some level.
 
c) By taking discussions to off-OLPC mailing lists, the opportunity for  "good samaritans" to wander by and make a contribution goes down, and there exists a  greater risk that the efforts/achievements (beyond that captured in the committed translation strings) will become less accessible (or even inaccessible) to others that might benefit later.
 
I'm not arguing against local autonomy, but in favor of a certain level of translingual collectivism, if you will.
 
cjl


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/localization/attachments/20080622/e2ce2254/attachment.htm