Hi, Brian
I had a look at the 0.6 i18n spec: Overall, it's a very nice carving
of a set of tasks out of a big chunky rock of a problem :). Comments
are below; quotes are from the doc and the text in [] is an attempt
to identify which part of the doc I'm talking about.
[Overview][Goals and Objectives]
The goal of this development cycle is to move Chandler from the 8-
bit english only space to the world of internationalization and
unicode.
When you say "8-bit english", do you really mean "ascii" (a.k.a. "7-
bit")?
Nit-picky naming question: Should it be i18nManager or I18Manager? I
guess it's hard to distinguish "I" and "1" in sans-serif fonts.
[0.6 Strategy]
Should maybe have a section about making our wx dialogs localizable.
Would this be done by having localizable .xrc files, and if so, are
there ways of making sure UI elements don't get "lost in translation"?
[The 0.6 Strategy][CPIA]:
3. Ensure that WxWidgets correctly converts keyboard input commands
to displayable glyphs in the correct language and perform character
set conversion when incoming textual data is not unicode
4. Ensure that all displayable blocks render multi-byte unicode
correctly.
It might be worth adding to 4: wxWidgets needs to be able to display
general multi-byte unicode correctly (not just multibyte unicode
entered via an input manager). It would be interesting to see how,
say, email messages with mixed R2L and L2R text will display on all
platforms.
<<<On reading further, this seems to end up being one of John
Anderson's tasks:
wxWdigets that display text are wrapping native Operating System
widgets
Is this realistic? e.g. aren't our table & grid controls non-native
(I'm no wx expert, so I could easily be off base here)?>>>
From [Tasks for Katie]:
Target languages of review could include Chinese, German, and Hebrew.
Hebrew (or Arabic for that matter) is a good one, since it will
unearth a large can o worms... Our UI layout is pretty much hard-
coded to be L2R: (e.g. positioning of (sidebar, summary, detail)
views, position of icons in sidebar, alignment of text in sidebar,
position of labels in detail view, alignment of text in detail view).
It would be good to call out whether this kind of layout
configurability is or is not a goal for 0.6 (my guess is not).
[General]
Somewhere, we probably need to point out that there is a lot of QA
work involved in verifying that Chandler works well with input
managers for different languages (especially given that these vary by
platform, too). Maybe this would be an area where outside volunteers
could help out.
<<<I wrote this before seeing Andrea's page, which is a much more
comprehensive outline of QA issues here>>>
[Some questions about the bigger proposal doc]
Are we going to output # c-format (or something similar) in .pot
files? In projects I've worked on in the past, inconsistent
translated format strings have caused a lot of grief (unexpected
raises, or crashes in C), and it would be good to be able to avoid this.
Lastly, because I'm a gettext newbie: Many translations require some
context (e.g. in the case of formatted strings, what the arguments
are). Is the gettext approach that translators figure that out from
the source file? (Ours was more that you'd add a comment in the
equivalent of the .pot file).
--Grant
Grant Baillie
Open Source Applications Foundation
http://www.osafoundation.org
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
