[Localization] code comments?

[Bert Freudenberg]

... 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  
> some
> sort of Quechua.
> Aymara is only spoken in some part of "Puno" region (and in many  
> places
> 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  
>> figure
>> 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  
>> phrase.
>> 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  
>> would
>> 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,  
>> even
>> 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  
>> languages
>> (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,  
>> which
>> is not necessarily evident.
>>
>> I do not know if this is even feasible at this stage of the game.   
>> While
>> 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  
>> and
>> further translations would bypass this kind of issues.
>>
>> Yama
>>
>> 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>  
>>>> wrote:
>>>>
>>>>> I was thinking about code documentation this morning.  If the  
>>>>> code is
>>>>> supposed to be readable all over the world then how does the  
>>>>> comments
>>>>> 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
>>> apply.
>>>
>>> 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  
>>> commenting
>>> 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  
>>> the
>>> program.  Maybe only """ commented text """ text would be  
>>> translated.
>>>
>>> Helping kids learn how to program is no different to me then  
>>> facilitating
>>> 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  
>>>> and
>>>> 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  
>>> self
>>> 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  
>>>> indented
>>>> to be used globally.  So English skill might be needed anyway to
>>>> understand the code very well ...
>>>>
>>>> /Korakurider