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

[Brian Kirsch]

Hi Markku,
You have some good observations and feature enhancements.

Can you condense these in to Bugzilla tasks so that they can be tracked.

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.

Can you detail why gettext is not working. Is it because of fuzzy 
duplication?

>
> 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 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.

>
> 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.

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.

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.

> 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