As much as I hate to say it cause I have had so much fun working on i18n :)
+1
It is more important to have a great app than an app that has great
localization
capabilities.
We are actually as far as we need to go with i18n in my opinion for 1.0.
I am finishing off the last of the tools to generate the .po files and
build the
localization eggs and should be done by tomorrow.
At that point it will be easy easy easy for someone to translate Chandler.
The XRC localization code is now in place and we are able to
pull strings contained in our XRC files in to our .pot templates and
localize them with no additional requirements.
The outstanding i18n issues are livable and some may in fact
be tackled in the 1.0 time frame:
1. The Repository localized strings need to be refreshed on locale change
2. The Chandler.exe file needs to support localizations
3. The Unit Tests leveraging i18n need to extend from a new Base class which
correctly initializes the i18n framework before the first call to
_() Message Factories.
Having said that my main concern is that the hard work that was put in
over the
past two dot releases is not lost.
Meaning that developers continue to correctly encode and decode Unicode
strings,
correctly work with the file system and third party API's, continue to wrap
translatable strings in _().
So I do think that we need to put a test plan in place to ensure that we
continue to
maintain the level of i18n support.
As a limitation to prevent i18n work from overshadowing our other
requirements
I am proposing that we do not accept translations from the community
till the 1.0 release.
The reason being is that once we accept a translation it has to be kept
in sync
through each dot release and that process is tedious and time consuming.
If someone from the community wants to write and maintain there own
translations externally and share them with other Chandler users that is
great.
Chandler now has the tools to make the translation task easy for them.
However, Philippe has offered to perform a French translation of
Chandler which
will serve as our reference implementation for Beta.
A demonstration of Chandler translated to French as well as a brief
tutorial on how
to build localization eggs will take place some time during the last
week of September when
I am at the OSAF office in SF.
Most likely it will be shown during office hours.
So to sum up!
We are far enough along with i18n now that attentions can be
focused elsewhere.
However, we do not want to jeopardized the i18n work that has already
been done and
thorough regression testing is essential.
-Brian
Katie Capps Parlante wrote:
Heikki Toivonen wrote:
We will soon need Internationalization, or Localization Freeze. Once
this is in effect, no changes will be allowed which affect localization.
Typically this would be somewhere between Feature Freeze and Code
Freeze.
I'll make the argument that we don't need this phase until later in
the process, after we have a few Beta releases under our belts.
Brian Kirsch, Markku, PJE and others have done a great job in moving
the i18n framework forward. Victory! Yes, there is more to do, but I
think we're well ahead of where we need to be as a project.
Given limited resources, I think it is important that we move our
attention to finishing up features (e.g. dashboard), improving
performance, fixing bugs and generally stabilizing the app. I'm really
loath to spend a lot more time on i18n at this stage in the process or
put localization requirements on ourselves that impact project
velocity -- we need to focus on having an app worth localizing!
Note that the above comments apply to Chandler. If I understand
correctly, i18n is not going to be a short term focus for Cosmo, so an
i18n freeze would not be applicable to the Cosmo process either.
Cheers,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
--
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 "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
