[Localization] code comments?
bert at freudenbergs.de
Sat Apr 5 03:31:30 EDT 2008
... which reminds me: Is it possible in gettext to fall back on a
language other than English when a translation for some phrase cannot
be found? That would be a useful feature I think, as long as there are
programs that are not fully translated (which will happen very often).
- Bert -
On 05.04.2008, at 07:55, info at olpc-peru.info wrote:
> English > Spanish > Aymara ?????
> I don't know what you are doing with Aymara. But Quechua is more
> "important" (numerically!!!)
> than Aymara language: 80% of the Peruvian Indian Population speaks
> sort of Quechua.
> Aymara is only spoken in some part of "Puno" region (and in many
> in Bolivia... I don't know
> if there is a OLPC project in Bolivia... but for Peru the first "extra
> language" is Quechua (in its
> four variations)... then Aymara.
> But... if you like Aymara!!! Let's do the Aymara thing! (smile).
> Best regards,
> Javier Rodriguez
> Lima, Peru
> Yama Ploskonka wrote:
>> I second this. By mistake I had sent a similar message to someone
>> in the
>> list, but not to the list, a few week back. the thread was
>> Re: [Localization] Problem: 2 translations for 1 string
>> I am no expert in OLPC msgid or .po files and am still trying to
>> poodle out in the cascading language problem (English -> Spanish ->
>> Aymara) where any such problems could very easily become silly,
>> especially if it happens in the hinge language.
>> One concept I have been toying with is that msgid be referred to
>> with an
>> univocal referent, like a database pointer, not with an English
>> The pointers would point to the English phrase in a similar structure
>> that they would point to any language phrase in any language.
>> ex.gr., BS07.en would be 'copy' and BS07.de would be 'Kopieren' and
>> BS07.es 'copiar'. There would be another instance of 'copy' that
>> be BS68.en, with a BS68.de translation as 'kopiere dich', and as many
>> instances as actual phrases happen in each context in the software,
>> if apparently they are the same in English. Reference pointer
>> would be
>> a number, or a construct that indicates package, class name, etc,
>> in the
>> software, and as add-on extension during execution (?) the language
>> code. Thus very little data could hold enormous amount of different
>> possible languages.
>> That would not solve all problems, since English IS the default
>> development language, yet English is somewhat poor in declensions and
>> all those funny endings that bring so much joy to many other
>> (Aymara is ripe with that) thus at the development stage it might
>> not be
>> noticed that a given term has to be contextualized. Also, still the
>> translator needs to know what sort of context the term is used in,
>> is not necessarily evident.
>> I do not know if this is even feasible at this stage of the game.
>> it would make all sort of localization issues much easier, it would
>> require a deep-down digging into the code.
>> In the long term it would be more than worth it, since maintenance
>> further translations would bypass this kind of issues.
>> Kent Loobey wrote:
>>> On Friday 04 April 2008 2:09:57 am you wrote:
>>>> On Sat, Mar 29, 2008 at 3:17 AM, Kent Loobey <kent at uoregon.edu>
>>>>> I was thinking about code documentation this morning. If the
>>>>> code is
>>>>> supposed to be readable all over the world then how does the
>>>>> within the code get translated?
>>>> I thought same thing. Source text is just text, I don't think we
>>>> want to embed comments for each language in same place (quite
>>>> difficult to read!).... Traditional code editing tools don't fit
>>>> well here. Any clue?
>>> I considered putting a number with each comment and then in a
>>> separate file
>>> putting a description for each number. However I think it would
>>> be better if
>>> the translated descriptions are inserted directly into the code
>>> where they
>>> A localization pre-processor might be run to insert translated
>>> text into the
>>> activity/program. I haven't done this myself but I know there are
>>> techniques that allow text to be pulled from programs to create a
>>> form of
>>> rudimentary documentation. Maybe we could do something along
>>> those lines and
>>> then reverse the process and insert the translated text back into
>>> program. Maybe only """ commented text """ text would be
>>> Helping kids learn how to program is no different to me then
>>> their learning anything else.
>>>> Besides comments in code, we understand code by name of class,
>>>> data, method. Good code have good names showing meaning clearly
>>>> that doesn't need much comment.
>>> I have been programming for a long long ... long long time. I
>>> have not
>>> however programmed in Python before. Python code by itself is not
>>> explanatory. So I don't believe that someone who has never
>>> programmed before
>>> could look at a Python program even with excellent class names and
>>> def names
>>> could figure out how it works.
>>> I agree that the constructs of a program are really just tags and
>>> don't make
>>> much difference what language they are in, i.e., a loop by any
>>> other name
>>> still just loops. Knowing why the loop is there is important to
>>> understanding what the program is doing and that takes language.
>>>> I think those are usually named in English if the code is
>>>> to be used globally. So English skill might be needed anyway to
>>>> understand the code very well ...
More information about the Localization