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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
