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

[Chris Leonard]

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/73a2aa44/attachment.htm