[Chandler-dev] Re: Chandler in French and in Finnish!

[Brian Kirsch]

Markku Mielityinen wrote:
> Brian Kirsch wrote:
>> Hi Markku,
>> You have some good observations and feature enhancements.
>>
>> Can you condense these in to Bugzilla tasks so that they can be tracked.
>
> I have already agreed to do that. I will also CC you in all the newly 
> generated bugs.
>
>> See comments in line.
>>
>> Thanks,
>> Brian
>>
>> Markku Mielityinen wrote:
>>> Philippe Bossut wrote:
>>>> Markku Mielityinen wrote:
>>>>> I was also supposed to write a small tutorial about my work, see 
>>>>> bug 6657, but as Philippe already beat me to the punch (only by a 
>>>>> day), I think that I am going to improve the wiki page that 
>>>>> Philippe already started.
>>>>>
>>>> Please do! That's the idea (it's a Wiki after all). Plus you're 
>>>> doing the work on Windows while I'm doing it on Mac.
>>>>
>>>> So far though, I have to say that the process has been incredibly 
>>>> easy... :)
>>>
>>> Yup, I have finished my current translation work, which took one 
>>> working day. The development tools that Brian made for automatic 
>>> building of translation eggs really make that part very easy. Also 
>>> the XRC pipe that I and Robin worked on seems to work perfectly. 
>>> However, there are a couple of things that I want to raise here:
>>>
>>> 1) The generated pot file contains a lot of duplicate entries which 
>>> unnecessarily take time when translating and they also prevent the 
>>> use of GNU gettext tool package.
>> Yes, the Chandler code base needs to be gone through to reduce string 
>> duplication. I originally creates the osaf.messages module to prevent 
>> this by having common used strings stored in one place. However, in 
>> hind sight I not a big fan of of the osaf.messages concept and 
>> probably will deprecate it at some point.
>>
>> So the best approach is to generate a .pot, manually read through it 
>> looking for duplications, then fix the offending Python / XRC source 
>> code. Once this process is done once any further examination in the 
>> future should be minimal.
>
> There is nothing wrong in having multiple requests from the same 
> string. We just need the tools to make sure that only one instance is 
> shown in pot files. All the requests can -- and should -- use the same 
> resource.
>
Sure I was not referring to multiple instances in code. I was talking 
about "like" instances in the .pot file. Ie. "Account Settings" and 
"Account settings" are functionally equivalent even though they are not 
100% duplications cause of capitalization.


>> Can you detail why gettext is not working. Is it because of fuzzy 
>> duplication?
>
> Recall our discussion 
> http://wiki.osafoundation.org/script/getIrcTranscript.cgi?channel=chandler&date=20060908 
> starting from 13:46.
>
> $ msginit -i Chandler.pot -l fi_FI -o test.po
> Chandler.pot:2404: duplicate message definition
> Chandler.pot:6: ...this is the location of the first definition
> msginit: found 1 fatal error
>
> It is not like we need this but someone might want to use it.
Hum, what is the string that is duplicated? I think this can be resolved 
easily I just need a bit more info on what exactly is causing the error.


>
>>
>>>
>>> 2) There are some duplicate entries due to differences in letter 
>>> capitalization. At some point we might want to consider unifying 
>>> these entries.
>>>
>> +1
>>>
>>> 3) There are still strings in source code that should be translated, 
>>> i.e. wrapped inside _(). For example displayName and startTime in 
>>> the header and Test menu, which we on the other hand might not want 
>>> to translate for other reasons.
>> The header menus should certainly be translated. I have spent much 
>> time on the past going through the app using the "test" locale to 
>> find non-translated strings and fix then. However, it has been a 
>> little while since I have done it and it sounds like some new 
>> translation misses have appeared.
>
> The example cases of displayName and startTime might be currently used 
> for debugging purposes.
>
>> The test menu strings we do not localize since it is only used by 
>> developers. The test menu tab should not be available in the 1.0 
>> release build.
>
> Agreed.
>
>>>
>>> 4) There are strings that are currently wrapped inside _() when they 
>>> should not be. The correct way to enter non-translated  strings is 
>>> to use _T() wrapper. For example ":", ":." etc.
>> I have found this to be an issue in the past as well. Developers for 
>> examples wrapping log messages in _(). There is really no way that I 
>> can think of to prevent this except to manually monitor check ins and 
>> alert the developer to mistake. This is really a coding style / 
>> developer issue.
>
> Yup.
>
>> I disagree on the _T() suggestion. We have no examples of this 
>> currently in Chandler code. The _T() paradigm is a C++ concept and 
>> not something used in Python projects.
>
> Yup, I discussed about this with heikkit and it seems that u"" is the 
> correct way to go.
>
>> Again there is a measure of developer responsibility in determining 
>> what should and should not be localized.
>>
>>>
>>> 5) Accelerated keys are currently wrapped in _() blocks. Whereas the 
>>> accelerated keys are typically localized, it is currently hard for 
>>> the translator to localize these in a consistent manner. Hence, we 
>>> might want to reconsider if localizing then, at least at this point, 
>>> is a good idea.
>> Yeah, I am not sure that localizing accelerator keys is a good idea 
>> at this point.
>> Another option is to have an alternate .po file and Project name 
>> spaces "ChandlerAccelerators" for  accelerator key definitions.
>>
>>
>>
>>>
>>> 6) There is some inconsistency in the way Show/Hide vs Hide/Show is 
>>> used. Perhaps we should choose one, Show/Hide, and use this order in 
>>> all places.
>>>
>>> 7) There is still some polishing to do: fixing typos and improving 
>>> the structure of some sentences. But hey, who is counting at this 
>>> point...
>> Yup this area could use some improvement.
>>
>>>
>>> In addition Philippe noticed that:
>>>
>>> 8) Building "MyTasks", "My..." by catenation of "My" and "..." does 
>>> not work for many locales.
>>>
>> That is a bug. A localization can not be build with concatenation.
>
> Yup.
>
>>> These are the experiences from our first (tentative) translations. 
>>> To sum it all up, I would say that Chandler is now 90-95% localized, 
>>> excluding the extension parcels, and the remaining work to increase 
>>> this to 100% is not large. Please feel free to post any comments 
>>> that you see related to the topic.
>>>
>>> Cheers,
>>>    Markku
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "chandler-dev" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>>
>

-- 
Brian Kirsch 
Internationalization Architect / Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
http://www.osafoundation.org