Hi Grant thanks for the feedback. Please see
comments in line.
Grant Baillie wrote:
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")?
Yes and no. I am referring to the Python string type
which is 8-bit so
saying ascii would technically not be correct. But
really yes I am
talking about ASCII.
Nit-picky naming question: Should it be
i18nManager or I18Manager? I
guess it's hard to distinguish "I" and "1" in
sans-serif fonts.
Ok sure I18NManager it is. Also FYI, the
ResourceLoader is being renamed
the I18NLoader since it is going to be used going
forward for more than
just loading of media resources.
[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"?
I think this is an important point but I an not sure
this needs to be
addressed in .6. Off the top of my head I would
guess it is going
require a custom .xrc file for each locale that
requires layout
alterations. This is gonna be a major pain not to
mention the
enforcement issues.
[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.
+1
R2L what is that? Ha hah
My guess is Chandler would barf but R2L is not a
priority for 1.0
anyways. Would be great to have though.
<<<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)?>>>
Good point I will follow up with the CPIA team and
see what the best
option is 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).
Complex layout is not a goal for .6 so I will make
it more clear in the
spec.
Hebrew is merely for the design team to review. The
point is to get
people thinking about these larger issues now even
though they will not
be tackled in the 1.0 timeframe. R2L also will not
be tackled but German
or Chinese might.
[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.
Agreed. I was waiting for feedback on the i18n
proposal before pointing
out specific QA tasks to make sure there were not
going to be any major
proposal changes.
QA will have a very important job in
Internationalization. Both manual
and automated tasks will need to be performed on
each target platform
and for each target language. It is not a trivial
task by any means.
Volunteers are certainly needed.
<<<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
