Hi Andi,
See comments in line.
Andi Vajda wrote:
On Wed, 16 Aug 2006, Brian Kirsch wrote:
Again two things:
1. wx does a much better job than PyICU at determining the
OS locale. That is why I use it.
If the wx code is better at doing this how about including it into ICU ?
I can take care of this if you point me at the wx code.
(PyICU only wraps ICU).
Yes I found wx was more accurate in determining the correct locale.
Especially when the OS locale was just changed.
Having said that the ultimate goal was to have our own Python wrappers
for each Operating System that would correctly get the entire locale set
as well as any custom date, numeric, and currency information specified
by user in the Operating System l10n configuration.
That project was just a bit to time consuming to tackle at the moment
given all the mail needs coming up for Beta.
So I made a choice to use the wx.Locale object for the short term.
The wx.Locale like the PyICU.Locale is only able to retrieve the
primary locale on the system.
As far why wx does a better job I can not say from a developer standpoint.
I would need to review the wx.Locale and the ICU.Locale code.
But in testing wx.Locale was more accurate.
Robin Dunn is a great resource for this type of information.
If you are really motivated we can look at trying to write the wrappers
to get
the OS l10n information. It just is time consuming as the c / C++ code
required will differ for each OS.
It's really important not to make upwards dependencies. wx (UI in
general) is higher up in the chain than ICU and anything that runs
without UI.
Yup, that is why I created a patch that bear is about to check in that
removes all
wx dependencies from the i18n code.
For example, the I18nManager now checks for the existence of the wx
package and
if present uses the wx.Locale to retrieve the default Operating System
locale
else it uses the PyICU.Locale.
Thus, Chandler headless integrity is preserved and the Chandler i18n
code can run without
wx installed :)
2. There is a very tight coupling between wx and i18n in that there
are many ways that the two must interact together to translate a UI.
However, as stated the wx code and the i18n can be run separately.
I understand that UI is a large part of localization. However, when
there is no UI involved, wx should not be required. Ideally (!),
headless Chandler should be able to run without any wx libraries even
loaded. Yes, I know, this goal is very far off at the moment but we
should be getting closer not farther.
It now is independent of wx as I described in the previous response.
As to your comment about the code in Application.py that was
commented out
in June, that was an entirely different issue. The use of wx in this
case is for locale and to set up and access the wx translation
libraries.
I'm still missing what wx has to do with these things. Yes, you said
that wx does a better job than ICU at determining the OS locale. If
that is the case, I'd like to improve ICU instead.
Could you please educate me on what the difference is ? what should
ICU do that wx does already ?
Again, from informal testing I found the wx.Locale did a much better in
picking up the correct Operating
System locale. I would need to take a few minutes to review the c / C++
code for the two modules before I could comment on what wx.Locale is
doing different from PyICU.Locale.
Improving PyICU Locale is certainly a worth while task.
I still need to test if a user enters custom l10n numeric, date, or
currency whether
the PyICU formatter classes pick this up.
For example, on OS X going to System Preferences/International/Formats
one can override the
defaults for numbers, dates, Calendar type (Gregorian), currency etc.
-Brian
Andi..
--
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
