[General] Milestones: i18n

[Brian Kirsch]

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