fosdem talk about l10n teams wishes
none
Philippe from the French localisation team (frenchmozilla).
I plan to make a talk at the fosdem 2007 about the wishes of the various
localisation teams.
I've already some ideas about our wishes, but perhaps we don't cover
everything.
So If you want yours to be included, talk about them here (or by mail
directly in my inbox : filip AD disque-monde.org ) and I'll try to
synthetise them in my speach.
Hope to see you in Bruxelles.
Philippe
Ricardo Palomares Martinez
I may be a bit insistent, but I still find too many deviations from
official specs on accesskeys naming, and there are still some
accesskeys that are defined in a DTD other than the one in which is
defined the label the accesskey is for. (Most of these problems should
be solved with Axel's L20n proposal)
And the greatest problem related to accesskeys for me, which is not
currently addressed by L20n AFAIK, is the ability to tie together
accesskeys used in a UI "unit" in which they can conflict, in a way
that allows a program checker to be written so localizers don't need
to manually review each UI one by one. I have made proposals for both
current L10n and L20n to solve it, but for L10n a massive renaming on
menu label entities should happen.
What else? Let me think... Oh, yes! Smaller patches for changes in
help files. This makes our life a LOT easier, because it allows diff
tools to get better reports of changes.
Also, the usual rant about trademark policies overload on final stages
before releases. :-)
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Axel Hecht
> none escribió:
>> Hello.
>> Philippe from the French localisation team (frenchmozilla).
>>
>> I plan to make a talk at the fosdem 2007 about the wishes of the various
>> localisation teams.
>>
>> I've already some ideas about our wishes, but perhaps we don't cover
>> everything.
>> So If you want yours to be included, talk about them here (or by mail
>> directly in my inbox : filip AD disque-monde.org ) and I'll try to
>> synthetise them in my speach.
>
>
> I may be a bit insistent, but I still find too many deviations from
> official specs on accesskeys naming, and there are still some
> accesskeys that are defined in a DTD other than the one in which is
> defined the label the accesskey is for. (Most of these problems should
> be solved with Axel's L20n proposal)
>
> And the greatest problem related to accesskeys for me, which is not
> currently addressed by L20n AFAIK, is the ability to tie together
> accesskeys used in a UI "unit" in which they can conflict, in a way
> that allows a program checker to be written so localizers don't need
> to manually review each UI one by one. I have made proposals for both
> current L10n and L20n to solve it, but for L10n a massive renaming on
> menu label entities should happen.
The main problem with this is that accesskeys cannot be solved for real.
To some extent, we're not trying to make accesskeys work beyond bugs,
apparently. See the pref window. In addition, in particular with
installed extensions, the participants in a accesskey context are not
initially known nor static.
I'm more focusing on automated testing here rather than huge amounts of
maintainance work.
> What else? Let me think... Oh, yes! Smaller patches for changes in
> help files. This makes our life a LOT easier, because it allows diff
> tools to get better reports of changes.
I may report that moving help content to the web is a P1 for Fx3,
http://wiki.mozilla.org/Firefox3/Firefox_Requirements_Meetings/Help_and_User_Support.
Though I personally have not heard about an implementation design yet.
> Also, the usual rant about trademark policies overload on final stages
> before releases. :-)
I'd call this "creating features without designing the l10n impact",
which I think is what's really biting us.
Axel
disque-monde. org
[...]
> I may be a bit insistent, [...]
> Also, the usual rant about trademark policies overload on final stages
> before releases. :-)
>
I'll talk about it (and Axel's response, no better : he'll respond in
live :)
If someone have something else that he want to be talked about, don't
hesitate.
Ph
Ricardo Palomares Martinez
> Ricardo Palomares Martinez wrote:
>> And the greatest problem related to accesskeys for me, which is not
>> currently addressed by L20n AFAIK, is the ability to tie together
>> accesskeys used in a UI "unit" in which they can conflict, in a way
>> that allows a program checker to be written so localizers don't need
>> to manually review each UI one by one. I have made proposals for both
>> current L10n and L20n to solve it, but for L10n a massive renaming on
>> menu label entities should happen.
>
> The main problem with this is that accesskeys cannot be solved for real.
I agree that there is no way to ensure that no accesskey conflict will
ever happen, no matter how many extensions are installed, but at least
the base product should be as clean as possible.
> To some extent, we're not trying to make accesskeys work beyond bugs,
> apparently. See the pref window.
Of course there are very difficult cases, but reducing it to a minimum
should raise the quality and be a good thing if there is an easy way
to get it.
> In addition, in particular with
> installed extensions, the participants in a accesskey context are not
> initially known nor static.
Agreed, see above.
> I'm more focusing on automated testing here rather than huge amounts of
> maintainance work.
I think I can't get you understand me in this kind of issues: I'm not
in any way suggesting that automated, centralized testing could be
made superfluous. But I'm pretty sure that people using MT, or
Translate Toolkit, or any other L10n solution, will be happier to
catch missing strings, faulty parameters, wrong accesskeys, etc.
before even committing the work into CVS, rather than waiting to get
the compare-locales.pl or tinderbox log (and, of course, before
manually reviewing the UI). I've used this analogy before: think of QA
controls in L10n tools as the JavaScript checks in web forms; both are
there to save time to user (if he cares to run them/have JS enabled),
even though the same checks must be done once the data gets to the
CVS/web server.
In the end, we must decide if there are solutions that are practical
enough and can save work in the long term for both developers and
localizers, and have a positive impact on final products.
> I may report that moving help content to the web is a P1 for Fx3,
> http://wiki.mozilla.org/Firefox3/Firefox_Requirements_Meetings/Help_and_User_Support.
> Though I personally have not heard about an implementation design yet.
No problem for me as I'm not in charge of Firefox L10n anymore and I
don't use it on a regular basis, but please SM Council, don't follow
Fx steps, at least until it is clear that it works better for
everyone. :-)
I really think that tracking changes in help will be a lot harder for
L10n teams if help is moved to the web. At least, spanish people
helping with MDC translation have that experience, following changes
in MDC to keep already translated content updated is a nightmare.
Rimas Kudelis
> The main problem with this is that accesskeys cannot be solved for real.
> To some extent, we're not trying to make accesskeys work beyond bugs,
> apparently. See the pref window. In addition, in particular with
> installed extensions, the participants in a accesskey context are not
> initially known nor static.
Actually, there's one possibility - dynamic accesskeys. I believe this
is implemented in BeOS, and I was quite amazed (and disturbed at the
same time) by such an idea – OS (GUI subsystem, to be exact) assigning
accesskeys itself. You may want to look at it.
RQ
Axel Hecht
I bet there are things like "accesskey contexts" that one could
maintain, but I'm not sure if we'd be running into a huge amount of
process overhead for things that can be relatively easy be debugged
post-mortem. More on that soon (TM).
>> I may report that moving help content to the web is a P1 for Fx3,
>> http://wiki.mozilla.org/Firefox3/Firefox_Requirements_Meetings/Help_and_User_Support.
>> Though I personally have not heard about an implementation design yet.
>
>
> No problem for me as I'm not in charge of Firefox L10n anymore and I
> don't use it on a regular basis, but please SM Council, don't follow
> Fx steps, at least until it is clear that it works better for
> everyone. :-)
>
> I really think that tracking changes in help will be a lot harder for
> L10n teams if help is moved to the web. At least, spanish people
> helping with MDC translation have that experience, following changes
> in MDC to keep already translated content updated is a nightmare.
>
Given that mconnor is going to be at fosdem, I'm happy to sit and watch
and tape any kind of fights arising :-)
I'll sell the tapes on ebay and keep all the revenue for myself :-)
Axel