On Jul 20, 2007, at 8:06 AM, Katie Capps Parlante wrote:
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.
I could not agree more. That is why any bugs I am logging are not
intended to be fixed for
Preview.
- 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.
Actually there were a number of bugs not related to any coding I did
(except for one) that were assigned to me while I was traveling for
EuroPython. When I left for Europe I only had one open Preview bug.
The new bugs all have a "Mail" component and thus ended up in my
bucket ie. "Can not remove an item from the In or Out Collection". I
will certainly do my best to address these bugs in a quick manner
even though in the majority of cases I am not actually the feature
set owner.
It goes without saying that Preview bugs take priority over any
localization work that needs
to be done.
However, I did need to take the time to write the EuroPython wrap up
so that we are all on the
same page as to the next steps needed for i18n / l10n.
- We will likely do a 0.7.1 release as a quick turn around.
Yes, this was a point I raised be it subtly in my EuroPython wrap up
email. I would rather get
the localization components right in a follow up release (7.1) then
put out an amateur effort
for Preview.
- 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 certainly think we can have French and Swedish versions of Chandler
given the
great work on the Swedish translation by Jonas and Jacob as well as
Philippe's
in house expertise in French.
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?
The majority of issues I raised in my wrap up page are intended to
be addressed post-Preview.
http://people.osafoundation.org/bkirsch/postsprint
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.
Thanks Katie.
-Brian
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
