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