[Design] Re: [Chandler-dev] EuroPython Localization wrap up and next steps

[Katie Capps Parlante]

Hi Philippe and Brian,

Its great to see the localization work come together, very exciting.

I want to make sure we step back and look at the larger context as we 
plan next steps...

- We don't want to threaten the Preview schedule, getting this out the 
door is critical.

- Preview is not a 1.0 release. Its a get something usable out the door 
so we can learn for the 1.0 release. The point of Preview is to put it 
out there and get feedback on things like the terminology and menus. We 
didn't perfect menus, terminology, error messages, etc. because we'd 
rather get feedback from users outside of our current bubble for the 
next iteration.

- Brian has more bugs than most -- are you a critical path? We need your 
concentration on those last tricky bugs.

- We will likely do a 0.7.1 release as a quick turn around.

- We are going to be doing a lot of iterating on 0.7.1 and subsequent 
releases.

I agree that we want people to be able to localize the Preview release. 
If something blocks that, we should fix it.

I do want to make sure we are being smart about next steps. Is any of 
this more appropriate for a 0.7.1 release?

If you guys tell me this is doable and won't put Brian on the critical 
path, I'm with you, but wanted to raise the issue.

Cheers,
Katie

Philippe Bossut wrote:
> Hi,
> 
> Heikki Toivonen wrote:
>> Maybe I misunderstood, because this does not make sense to me:
>>
>> So you are saying we will not change strings in Chandler code, but you
>> will manually change Chandler.pot, which should be used by translators
>> to create po files?
>>   
> 
> You misunderstood what Brian said. His point is : the strings in the 
> code (the untranslated ones that are used as msgid if you prefer) are 
> not good, the English is poor, the wording is inconsistent, etc... which 
> makes the work of translators hard. So we should make our best effort to 
> change them before we start localization for good. 2 points are making 
> that a tad tricky:
> - We are in a "string freeze" period and we asked devs not to change 
> those strings (but that's a constraint we added on ourselves, not a law 
> of physics)
> - We better have that done by one person so that consistency is indeed 
> achieved. Turns out that this is what Mimi's just done with her 
> Chandler-en.po
> 
> So the proposal is:
> 1- Mimi tweaks the Chandler-en.po may be once more (actually she logged 
> bug 9954 against herself to do just that). Note that Mimi prefers 
> working on the po rather than the Python and xrc because in the po you 
> have all the strings right here and there and you can ensure consistency 
> in a much easier way.
> 2- When done, Brian makes the manual changes of the strings in Python 
> and xrc files. Other devs please continue to respect the "string freeze" 
> or his and Mimi's work will be made that much harder.
> 3- When all the substitutions are done, we'll create a new Chandler.pot 
> (using the usual createpot tool) that we'll commit in the localizations 
> svn and we'll give the "go" to other localizers to start their work
> 
> Note that this operation will likely make the use of a Chandler-en.po 
> much less critical, except for those stray strings that we may want to 
> tweak once more post point 3.
> 
> Does it make more sense?
> 
> Brian, Mimi, please chime in if I miss something.
> 
> Cheers,
> - Philippe
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design