Localization process
Cédric Corazza
To avoid any misunderstanding, I'm speaking in my own name, this is not
a "fatwa" or a troll ot whatever, but I've got some feelings:
- I'm *really* amazed about the comments I could read in the late l10n
comments bugs from the MoCo/MoFo decision-makers: "we would want take
this *if* there is a RC2 release" (well, something like that). I thought
we were a community and MoFo/MoCo only releases stuff when it's ready;
unless that means when en-US is ready? There are about over 40 locales
to be released, and many have some pending bugs about the help stuff.
So, that would mean that decision-makers are ready to release localized
Firefox builds with crappy help?
- if MoFo/MoCo plans to release Firefox 2.0 earlier than October 25th
(or so), please, let know the community about that as FF 2.0 parties are
planned
- there is still a full month if FF 2.0 would be released on 25/10 for
localizers to check help files if we are allowed to check patches in;
lots of QA tests have been already made, and for Help files, we know
what to check
- and last, maybe it's worth to be recalled, this is not a full time job
for localizers to maintain their locale, and help changes occurred very
lately in the process.
I don't remember Firefox 1.0 and 1.5 releases were so "hasty", though
(and thanks for that) we have now Axel who works hard to handle l10n
concerns.
Regards
Damjan Georgievski
> (and thanks for that) we have now Axel who works hard to handle l10n
> concerns.
It would be really, REALLY great if MoFo/Co allows for l10n updates for the
2.0.0.1 release.
The thing is, until 2.0 ships we just can't get enough testing, the size of
the community available for testing a pre-release product is.. well... at
most 3 guys doing it from time to time.
Sorry, but that's it, we are a small country, not many people, not very much
Internet users either, and while I don't know how many of the Internet
population uses Firefox, I bet it's very small percentage that uses l10n
Firefox ... and even less that could create meaningfull bug reports.
In other projects, like KDE for example, the first .1 release is almost
always for l10n updates.
And you should really ease off the whole create ticket/wait for approval
mambo/jumbo... it's tiring and it's not like we are trying to screw things
over.
--
damjan
Marek Stępień
>> I don't remember Firefox 1.0 and 1.5 releases were so "hasty", though
>> (and thanks for that) we have now Axel who works hard to handle l10n
>> concerns.
>
> It would be really, REALLY great if MoFo/Co allows for l10n updates for the
> 2.0.0.1 release.
These will obviously be allowed, like they were for 1.5.0.1 up to 7 and
counting.
The current lockdown is for 2.0.0.0 only (more precisely, for 2.0.0.0 RC
1; if there's gonna be an RC 2 there will be another window for
checking stuff in).
--
Marek Stępień <mar...@aviary.pl>
AviaryPL - polski zespół lokalizacyjny Mozilli
http://www.firefox.pl/ | http://www.mozilla.org.pl/
Francesco Lodolo
> These will obviously be allowed, like they were for 1.5.0.1 up to 7 and
> counting.
were only short time frames for check-ins and not for every release
(maybe things will change for 2.0.x)
Just an example:
https://bugzilla.mozilla.org/show_bug.cgi?id=317106
We were able to correct the problem only in Firefox 1.5.0.4
Francesco.
Axel Hecht
> Damjan Georgievski napisał(a):
>>> I don't remember Firefox 1.0 and 1.5 releases were so "hasty", though
>>> (and thanks for that) we have now Axel who works hard to handle l10n
>>> concerns.
>> It would be really, REALLY great if MoFo/Co allows for l10n updates for the
>> 2.0.0.1 release.
>
> These will obviously be allowed, like they were for 1.5.0.1 up to 7 and
> counting.
>
> The current lockdown is for 2.0.0.0 only (more precisely, for 2.0.0.0 RC
> 1; if there's gonna be an RC 2 there will be another window for
> checking stuff in).
>
We didn't allow l10n fixes into the minor releases up to some pretty
high .n number, mainly because we were struck in getting together about
the process.
We will do for 2.0.0.x what we're doing for 1.5.0.x, that is, l10n
changes will have the same engineering window as en-US, and approvals
will go through the same queue (the latter with a 'likely').
There are still things that we need to shake out, but I need some time
with at least schrep on that, and he's, well, kinda busy these days.
Axel
Axel Hecht
> Hi.
> To avoid any misunderstanding, I'm speaking in my own name, this is not
> a "fatwa" or a troll ot whatever, but I've got some feelings:
> - I'm *really* amazed about the comments I could read in the late l10n
> comments bugs from the MoCo/MoFo decision-makers: "we would want take
> this *if* there is a RC2 release" (well, something like that). I thought
> we were a community and MoFo/MoCo only releases stuff when it's ready;
> unless that means when en-US is ready? There are about over 40 locales
> to be released, and many have some pending bugs about the help stuff.
> So, that would mean that decision-makers are ready to release localized
> Firefox builds with crappy help?
Basically, yes. If you ask me, even more than that. en-US help has bugs
open that are already fixed in the l10n repository, so, honestly, en-US
help is likely in worse shape than some of it's localizations. For the
latest bugs, I started to request ports of those fixes to l10n, and got
those, too, thanks to Steffen.
I am thinking quite a bit of what has become of help, and really, I took
a look, and it's ..., 'nuff said. I really think we need a plan to
unsuck help, and that's not a question of 'shipped or web'. We have a
process problem here, and one of manpower. Anyway, .l10n is hardly the
right forum to discuss this, and I'm not sure if this discussion is one
to start in public, too. At least parts of the story in my head are
surely not.
About the decisions we're posting, here's how it's done:
- Software is never bug free. Sad but true.
- We have a deadline coming up, we really want to ship before IE7
Thus, the question that we have to answer is not
- Would a user like this fix?
but
- Would all users of Firefox worldwide would like to wait a week (at
least) on Firefox 2 for this fix?
I don't think that a week is really all it takes for another RC, but
that's the lower bound.
As I have said down the thread, we do intend to take l10n fixes on the
stable 2.0 branch as we're doing on the stable 1.5 branch, and now that
we know how that works, we will do so right from the start. At least I
haven't heard the contrary. Firedrills excluded, of course.
So we want localizers to think down the same route: Do you think that
this particular fix in its own right requires a respin? Like, would we
release a 2.0.0.1 if we didn't take it now?
If not, then you're welcome to suggest patches for take-along. The
general idea of "we have a bunch of l10n help fixes" is part of our
thinking about RC2, but they're not the initial trigger of it happening
or not. I didn't see the en-US-version of the help bug mentioned, btw.
I should have more on whether we have an RC2 or not tonight.
> - if MoFo/MoCo plans to release Firefox 2.0 earlier than October 25th
> (or so), please, let know the community about that as FF 2.0 parties are
> planned
> - there is still a full month if FF 2.0 would be released on 25/10 for
> localizers to check help files if we are allowed to check patches in;
> lots of QA tests have been already made, and for Help files, we know
> what to check
> - and last, maybe it's worth to be recalled, this is not a full time job
> for localizers to maintain their locale, and help changes occurred very
> lately in the process.
We do. That's why we said a week of time for the prefwindow-reorg-help
landing, which I estimate to be, depending on language skills, more in
the range of less-than-a-day, in terms of real work. That time did
include that some localization teams did adjust their habits to how
fuzzy the help process is, too.
> I don't remember Firefox 1.0 and 1.5 releases were so "hasty", though
> (and thanks for that) we have now Axel who works hard to handle l10n
> concerns.
I recall 1.5 to be worse in terms of process, though help pretty much
runs through my parade like a truck driven by the governor of California.
I hope I could clear up some of the terms used by drivers, and give you
an introduction on how the decisions at this point in time are made, and
communicated.
Axel
Marek Stępień
> About the decisions we're posting, here's how it's done:
>
> - Software is never bug free. Sad but true.
> - We have a deadline coming up, we really want to ship before IE7
But IE7 isn't shipping in November, is it?
> - Would all users of Firefox worldwide would like to wait a week (at
> least) on Firefox 2 for this fix?
[...]
> So we want localizers to think down the same route: Do you think that
> this particular fix in its own right requires a respin? Like, would we
> release a 2.0.0.1 if we didn't take it now?
Well, certainly pl users will not want to wait a week for a fix in zh-CN
nor vice versa, but we have lots of fixes for many of the locales, not
just one.
There are at least 10 bugs that have fixes for help content or window
sizing. There are probably also other l10n teams that would fix the help
if they were allowed to. I'm not sure if we're making it really clear to
the teams that they should provide patches even if they're not going
to make it into RC 2.
In my opinion, if many of the so-called tier-1 or tier-2 locales are
somehow broken (whether it's help, pref window sizing or else), we
should at least evaluate the possibility of making a respin.
Missing help stuff in one locale is not a problem that would require
a respin, but if help is incomplete in (let's say) 10 locales, then
this _is_ a real problem. Note that in some countries the government
requires translated documentation, so not having localized help
in Firefox keeps this browser out of government institutions.
We wouldn't have this problem if the en-US help update was made
earlier - e.g. about the time when the actual pref window changes
were made, and/or if there had been more time for letting the
localizers translate the English files.
> We do. That's why we said a week of time for the prefwindow-reorg-help
> landing, which I estimate to be, depending on language skills, more in
> the range of less-than-a-day, in terms of real work.
While, indeed, it took me about 10 hours to update the help stuff,
it took three more days to catch all the mistakes in it. And it's *only*
been so fast because of the fact that I still have vacation (in Polish
universites the classes start on Oct 1st).
> That time did
> include that some localization teams did adjust their habits to how
> fuzzy the help process is, too.
I don't really understand what you mean by this, but if you're talking
about teams waiting for the en-US patch to be finalized, I fully
understand them. We can't make a complete help l10n if the keys
in *.rdf files keep changing. Some guys may not have time
to read all the patches getting attached to the en-US help bug.
>> I don't remember Firefox 1.0 and 1.5 releases were so "hasty", though
>> (and thanks for that) we have now Axel who works hard to handle l10n
>> concerns.
>
> I recall 1.5 to be worse in terms of process, though help pretty much
> runs through my parade like a truck driven by the governor of California.
Maybe I don't remember this correctly, but for 1.5 the pref window
changes were documented in en-US help way sooner than for 2.0.
I even don't remember any problems with 1.5 help that pl would suffer,
though I am sure I will remember the 2.0 help situation for a long time.
Axel Hecht
> Axel Hecht napisał:
>> About the decisions we're posting, here's how it's done:
>>
>> - Software is never bug free. Sad but true.
>> - We have a deadline coming up, we really want to ship before IE7
>
> But IE7 isn't shipping in November, is it?
I personally couldn't care less, really. That's why I'm not doing our
schedule.
>> - Would all users of Firefox worldwide would like to wait a week (at
>> least) on Firefox 2 for this fix?
> [...]
>> So we want localizers to think down the same route: Do you think that
>> this particular fix in its own right requires a respin? Like, would we
>> release a 2.0.0.1 if we didn't take it now?
>
> Well, certainly pl users will not want to wait a week for a fix in zh-CN
> nor vice versa, but we have lots of fixes for many of the locales, not
> just one.
>
> There are at least 10 bugs that have fixes for help content or window
> sizing. There are probably also other l10n teams that would fix the help
> if they were allowed to. I'm not sure if we're making it really clear to
> the teams that they should provide patches even if they're not going
> to make it into RC 2.
>
> In my opinion, if many of the so-called tier-1 or tier-2 locales are
> somehow broken (whether it's help, pref window sizing or else), we
> should at least evaluate the possibility of making a respin.
As I already said, we do. But not one of the help patches I have seen so
far would really make a case for not shipping Firefox 2. Broken en-GB
would, but that's fixed. And a broken search plugin for zh-TW might,
though that wouldn't really make us respin all. Sizing of one
screenshot? That's a take-along, not a reason for a respin.
> Missing help stuff in one locale is not a problem that would require
> a respin, but if help is incomplete in (let's say) 10 locales, then
> this _is_ a real problem. Note that in some countries the government
> requires translated documentation, so not having localized help
> in Firefox keeps this browser out of government institutions.
Could you fill in some detail here? Documentation could be anything,
starting from a single entity that says "This is a browser, you can
click on links. Those are the blue texts with underlines." The other end
of the spectrum could be that each dialog had to have a document, it
must be accessible with Crtl-F1, the shown doc needs to be accessible,
with ... .
> We wouldn't have this problem if the en-US help update was made
> earlier - e.g. about the time when the actual pref window changes
> were made, and/or if there had been more time for letting the
> localizers translate the English files.
>
>> We do. That's why we said a week of time for the prefwindow-reorg-help
>> landing, which I estimate to be, depending on language skills, more in
>> the range of less-than-a-day, in terms of real work.
>
> While, indeed, it took me about 10 hours to update the help stuff,
> it took three more days to catch all the mistakes in it. And it's *only*
> been so fast because of the fact that I still have vacation (in Polish
> universites the classes start on Oct 1st).
10 hours for prefs.xhtml, or all the other help files, too?
What kind of bugs did you find?
>> That time did
>> include that some localization teams did adjust their habits to how
>> fuzzy the help process is, too.
>
> I don't really understand what you mean by this, but if you're talking
> about teams waiting for the en-US patch to be finalized, I fully
> understand them. We can't make a complete help l10n if the keys
> in *.rdf files keep changing. Some guys may not have time
> to read all the patches getting attached to the en-US help bug.
What the German team did was to not work on help at all before the prefs
patch landed. And that is indeed piling up a lot of work which wasn't
totally necessary.
>>> I don't remember Firefox 1.0 and 1.5 releases were so "hasty", though
>>> (and thanks for that) we have now Axel who works hard to handle l10n
>>> concerns.
>> I recall 1.5 to be worse in terms of process, though help pretty much
>> runs through my parade like a truck driven by the governor of California.
>
> Maybe I don't remember this correctly, but for 1.5 the pref window
> changes were documented in en-US help way sooner than for 2.0.
> I even don't remember any problems with 1.5 help that pl would suffer,
> though I am sure I will remember the 2.0 help situation for a long time.
I didn't talk at all about help or prefwindow in 1.5. I was more talking
about search and bookmarks, and I think that got much better documented,
and executed, with the help of Mic and Phil.
As I have stated in my previous post, I won't go into discussing the
consequences of the current help situation. I'll take notes on the input
we get here, though. That's why I ask more question instead of answering
any.
Axel
Marek Stępień
>> But IE7 isn't shipping in November, is it?
> I personally couldn't care less, really. That's why I'm not doing our
> schedule.
AFAIK it's not, it's shipping with Vista in 2007. So, we can still be
ahead of IE 7 with an RC 2 or even RC 3, if that's needed.
> As I already said, we do. But not one of the help patches I have seen so
> far would really make a case for not shipping Firefox 2. Broken en-GB
> would, but that's fixed. And a broken search plugin for zh-TW might,
> though that wouldn't really make us respin all. Sizing of one
> screenshot? That's a take-along, not a reason for a respin.
Sizing of one screenshot certainly not, but having help that describes
a completely different pref window...?
> Could you fill in some detail here? Documentation could be anything,
> starting from a single entity that says "This is a browser, you can
> click on links. Those are the blue texts with underlines." The other end
> of the spectrum could be that each dialog had to have a document, it
> must be accessible with Crtl-F1, the shown doc needs to be accessible,
> with ...
The general rules in Poland are that the Polish "user's manual"
must be present, though it may be reasonably shorter than the original one.
This doesn't usually apply to free software apps, but to the
ones that are paid for, but you never known what absurds the clerks may
invent. ;-)
However: IANAL.
> 10 hours for prefs.xhtml, or all the other help files, too?
> What kind of bugs did you find?
Mainly prefs.xhtml, as the others were either already fixed,
or the changes were minor. "Bugs" - some spelling mistakes, punctuation,
general polishing ;-) of everything.
When the deadline was moved a few days ahed, I also rewrote
glossary.xhtml from scratch, as it was like "TCP/IP Guru Handbook"
rather than what a typical user would like to read. However,
this is specific to pl.
> What the German team did was to not work on help at all before the prefs
> patch landed. And that is indeed piling up a lot of work which wasn't
> totally necessary.
That's why I'm updating branches and trunk continuosly... I prefer to
work 10 minutes each day than to do the whole job in a week once a year. ;-)
> I didn't talk at all about help or prefwindow in 1.5. I was more talking
> about search and bookmarks, and I think that got much better documented,
> and executed, with the help of Mic and Phil.
Documented better, indeed. More bureaucratic as well, though.
Axel Hecht
> Axel Hecht napisał(a):
>>> But IE7 isn't shipping in November, is it?
>> I personally couldn't care less, really. That's why I'm not doing our
>> schedule.
>
> AFAIK it's not, it's shipping with Vista in 2007. So, we can still be
> ahead of IE 7 with an RC 2 or even RC 3, if that's needed.
>
>> As I already said, we do. But not one of the help patches I have seen so
>> far would really make a case for not shipping Firefox 2. Broken en-GB
>> would, but that's fixed. And a broken search plugin for zh-TW might,
>> though that wouldn't really make us respin all. Sizing of one
>> screenshot? That's a take-along, not a reason for a respin.
>
> Sizing of one screenshot certainly not, but having help that describes
> a completely different pref window...?
Tough call. It's gotta be ship or not ship. We're not going to postpone
a ship of Firefox 2 on that. If it takes longer than a week, how long is
it allowed to take?
We clearly communicated, this week is for localizing prefs.xhtml, and I
hope we said often enough that we need feedback on anything that doesn't
work. I haven't heard anything during that week.
We have been communicating that help is optional, over and over. So long
that we actually believed that ourselves. That's my short analysis, and
that bit us in the butt. We just don't have the time to fix that for
Firefox 2, and we need to make the call on each locale if users are
better off with 1.5 or 2.0 in it's current form.
Not that I have any clue whatsoever if the translated help files on the
1.5 tree have anything to do with the UI that we ship. I'm generally of
good faith here, but not to a 100%.
>> Could you fill in some detail here? Documentation could be anything,
>> starting from a single entity that says "This is a browser, you can
>> click on links. Those are the blue texts with underlines." The other end
>> of the spectrum could be that each dialog had to have a document, it
>> must be accessible with Crtl-F1, the shown doc needs to be accessible,
>> with ...
>
> The general rules in Poland are that the Polish "user's manual"
> must be present, though it may be reasonably shorter than the original one.
>
> This doesn't usually apply to free software apps, but to the
> ones that are paid for, but you never known what absurds the clerks may
> invent. ;-)
>
> However: IANAL.
So the way that thunderbird offers help (no direct links between UI and
help content, just a set of web pages) is good enough?
>> 10 hours for prefs.xhtml, or all the other help files, too?
>> What kind of bugs did you find?
>
> Mainly prefs.xhtml, as the others were either already fixed,
> or the changes were minor. "Bugs" - some spelling mistakes, punctuation,
> general polishing ;-) of everything.
>
> When the deadline was moved a few days ahed, I also rewrote
> glossary.xhtml from scratch, as it was like "TCP/IP Guru Handbook"
> rather than what a typical user would like to read. However,
> this is specific to pl.
What makes help take so long? I've just been reviewing a help content
patch (the first I really ever looked at closely), is it the technical
complexity of search/toc/xhtml files? Or is that full-text translation
does require more or less different language genes? What else?
I had no idea how long it would take me to write down prefs.xhtml in
German, but then I know that writing is not part of my skillset.
>> What the German team did was to not work on help at all before the prefs
>> patch landed. And that is indeed piling up a lot of work which wasn't
>> totally necessary.
>
> That's why I'm updating branches and trunk continuosly... I prefer to
> work 10 minutes each day than to do the whole job in a week once a year. ;-)
>
>> I didn't talk at all about help or prefwindow in 1.5. I was more talking
>> about search and bookmarks, and I think that got much better documented,
>> and executed, with the help of Mic and Phil.
>
> Documented better, indeed. More bureaucratic as well, though.
>
Blame we-know-who ;-)
Axel
Marek Stępień
> So the way that thunderbird offers help (no direct links between UI and
> help content, just a set of web pages) is good enough?
As long as the users get at least some basic usage information in the
native language, yes.
> What makes help take so long? I've just been reviewing a help content
> patch (the first I really ever looked at closely), is it the technical
> complexity of search/toc/xhtml files? Or is that full-text translation
> does require more or less different language genes? What else?
Technical complexity of the RDF is one thing (well, not all the l10n
teams are made of geeks like us who know what a subject-predicate-object
expression is), but I'd rather blame the amount of text to translate.
It doesn't really matter whether the 300 KB patch is for dtd's or xhtml
files, it's still 300 thousand characters == tens of thousands
of words.
For smaller teams this may be a problem, especially if their only
member can work on this for no more than an hour a day. Gandalf warned
that a week may not be enough, and it turned out he was right on this.
Marek Stępień
> It doesn't really matter whether the 300 KB patch is for dtd's or xhtml
> files, it's still 300 thousand characters == tens of thousands
> of words.
Oops, 300K is the wrong number, the actual patch was like 100 K.
wc -w prefs.xhtml gives about 4K words in prefs.xhtml (with html tags
included, though).
So, 4K, not tens of thousands. Still a lot, though.
For comparison, browser.dtd in pl is 1607 words according to wc -w.
(Though for a real number one should subtract <!ENTITY> tags, entity
names and HTML tags)
Cédric Corazza
> patch (the first I really ever looked at closely), is it the technical
> complexity of search/toc/xhtml files? Or is that full-text translation
> does require more or less different language genes? What else?
> I had no idea how long it would take me to write down prefs.xhtml in
> German, but then I know that writing is not part of my skillset.
>
The mere translation job of help files is not difficult in itself. What
takes lot of time is to check that every described item has the same
label in the UI and in the Help section. That's why we chose for fr to
use DTD's entities to stay synch, so that in case of fixing a typo or
rewording something in a dtd file, it "updates" at the same time help
file; and if an entity disappears or is renamed, we've got a beautiful
red line, so that, we know help is not up to date.
In the case of prefs.html diff, several paragraphs were moved, some
slightly changed, some IDs and anchors were changed too, some paragraphs
were added also. So we had to check if we already translated those
paragraphs, check if they were slightly changed, and so on. This is very
time consuming. It might have been easier to handle for localizers if,
for instance, this huge patch (+- 584/474) had been sliced into several
little ones, like one for each prefs panel for instance (or even tab in
the panel), as the diffs would have been easier to read.
Though, I agree that small help diff file (about 10 to 20 lines) are
rather easy to handle and not time consuming
Regards
Ricardo Palomares Martinez
>
> We do. That's why we said a week of time for the prefwindow-reorg-help
> landing, which I estimate to be, depending on language skills, more in
> the range of less-than-a-day, in terms of real work. That time did
> include that some localization teams did adjust their habits to how
> fuzzy the help process is, too.
I can't agree with that estimation. Just prefs.xhtml had a lot of
material to catch up, and the biggest problem with it was in bonsai
diff being essentially useless:
If some text was moved from one place to another inside the file,
that's impossible to find out just from the diff. Basically, I had to
go through the whole en-US file comparing HTML id attributes with
es-ES version and trying to guess when there was reusable texts.
Besides, "less-than-a-day in terms of real work" is a somewhat fuzzy
measure. For a paid employee, that could mean eight-ten hours and
maybe the estimation would be right. To me, devoting more than
two-three hours per day when I'm not on vacation would be a real
luxury; I think I needed three or four natural days just for
prefs.xhtml. I don't know how much time can grab other localizers for
L10n (BTW, this could be a future topic once the dust is settled).
And I still think that I have got something wrong regarding the
lockdown-bug-path-request-approval process. The tree was closed on
Sep. 18, 17:30 UTC [1], more or less, and the deadline for approving
bugs filed requesting further changes to L10n ended about 24 hours
later [2]. I sincerely expected something like a week for *controlled*
changes in localizations. If 24 hours is what we can expect, just drop
the bug-patch-approval approach, and simply tell us with that same 24
hours of advance when the tree will be closed.
[1] http://groups.google.es/group/mozilla.dev.l10n/msg/f0fd0c01902cf370
[2]
http://groups.google.es/group/mozilla.dev.planning/msg/4b92db70b824cea3?
Again, don't get this as a complain to you. I (and surely everyone
commenting in this thread) just want to point out where the process
can be made easier, clearer and resulting in a final better product.
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Axel Hecht
> Axel Hecht escribió:
>> We do. That's why we said a week of time for the prefwindow-reorg-help
>> landing, which I estimate to be, depending on language skills, more in
>> the range of less-than-a-day, in terms of real work. That time did
>> include that some localization teams did adjust their habits to how
>> fuzzy the help process is, too.
>
>
> I can't agree with that estimation. Just prefs.xhtml had a lot of
> material to catch up, and the biggest problem with it was in bonsai
> diff being essentially useless:
>
> http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/browser/locales/en-US/chrome/help&command=DIFF_FRAMESET&file=prefs.xhtml&rev1=1.34.2.15&rev2=1.34.2.16&root=/cvsroot
>
> If some text was moved from one place to another inside the file,
> that's impossible to find out just from the diff. Basically, I had to
> go through the whole en-US file comparing HTML id attributes with
> es-ES version and trying to guess when there was reusable texts.
>
> Besides, "less-than-a-day in terms of real work" is a somewhat fuzzy
> measure. For a paid employee, that could mean eight-ten hours and
> maybe the estimation would be right. To me, devoting more than
> two-three hours per day when I'm not on vacation would be a real
> luxury; I think I needed three or four natural days just for
> prefs.xhtml. I don't know how much time can grab other localizers for
> L10n (BTW, this could be a future topic once the dust is settled).
That was what Cedric was comparing to, "not full time job", so I gave an
example of what my idea of timing would have been for someone that would
do Mozilla Localizations as full time job, with no other priorities than
coffee and taking a leak. We all understand that there are no such
persons, and thus, the timelines look different.
> And I still think that I have got something wrong regarding the
> lockdown-bug-path-request-approval process. The tree was closed on
> Sep. 18, 17:30 UTC [1], more or less, and the deadline for approving
> bugs filed requesting further changes to L10n ended about 24 hours
> later [2]. I sincerely expected something like a week for *controlled*
> changes in localizations. If 24 hours is what we can expect, just drop
> the bug-patch-approval approach, and simply tell us with that same 24
> hours of advance when the tree will be closed.
I didn't post to .110n first thing on tree closure. The tree closed at
9am PDT, I did update tinderbox, topic in #l10n, posted to .l10n, had a
conf call which I have daily at 9am PDT etc. Note, the tree closes when
announced in advance, not when the 15th of all possible communication
channels received a note on it. I probably posted that message because I
saw check-ins post-freeze.
Later on, we found out that we're having problems with en-US and
wouldn't be able to kick off the l10n builds Monday morning, so we
decided to use that time on short notice. We were able to take some
valuable fixes in that time, but that doesn't mean that we should plan
to have problems in the en-US build a week up-front.
> [1] http://groups.google.es/group/mozilla.dev.l10n/msg/f0fd0c01902cf370
> [2]
> http://groups.google.es/group/mozilla.dev.planning/msg/4b92db70b824cea3?
>
>
> Again, don't get this as a complain to you. I (and surely everyone
> commenting in this thread) just want to point out where the process
> can be made easier, clearer and resulting in a final better product.
I think there is a common pitfall in quite a few heads, and it left mine
not too long ago. When schrep talks about a release candidate, he really
means that. RC is RC is RC. There is no need for an RC2, unless someone
broke something badly. Otherwise, we can take those very bits and push
them to the server. I have seen versions of the bonecho calendar myself
that had an RC2 scheduled a while ago, but schrep apparently hunted that
one down. Those dialing in to the weekly bonecho meeting learned that
lesson by now, but I'm not sure how aggressively he messaged that in his
posts. I'm confident that localizers aren't the only ones being puzzled
about that.
I think it is essential to point out that any release process will be
made by day-to-day decisions at this point in the release cycle, or even
more short term. All the communication about those decisions will have
losses in information. Notes of the release meetings will naturally be
brief and summarizing, too.
How many of you folks are following .planning? I would think that you'd
want to.
Axel
Jeff Walden
Marek Stępień wrote:
> But IE7 isn't shipping in November, is it?
IE7 shipped yesterday, and we ship a few days later, by my time zone. (Not that I'm well-informed enough to know whether this timing is good or bad, but since this question can now be answered...)
> Well, certainly pl users will not want to wait a week for a fix in zh-CN
> nor vice versa, but we have lots of fixes for many of the locales, not
> just one.
I'm curious -- in retrospect, was the "do it for RC2" approach truly insufficient? I suppose it was a gamble that there'd be an RC2, but I for one would have taken and will continue to take that bet *any* day, for *any* Firefox release, regardless what anyone says about RCs being completely, utterly, totally release-worthy.
> We wouldn't have this problem if the en-US help update was made
> earlier - e.g. about the time when the actual pref window changes
> were made, and/or if there had been more time for letting the
> localizers translate the English files.
I'll take blame for this one. Had I made it an issue, I probably could have gotten the update done at the same time as the actual implementation (and avoided a few bugs in the process -- Choose/Browse comes to mind most readily). I suspect it would have taken longer than doing it as it actually happened (no incentive like time pressure to get things done quickly, although by the second-to-last panel or so I was *really* dragging mentally, and no initial implementation from which to work and derive wording and content inspiration), but it would have been better in a bunch of different ways. Whether it would have been better overall (prefwindow done in a timely manner, patch to doc it been as good as it turned out, nits aside, etc.) is *maybe* arguable, but that ship's long sailed. In the future, however, I'd definitely insist on doc-ing and coding simultaneously.
> And it's *only* been so fast because of the fact that I still have
> vacation (in Polish universites the classes start on Oct 1st).
I didn't when I wrote the patch, for what it's worth. I don't remember how severe the consequences of that were, if I ended up having any.
>>> I don't remember Firefox 1.0 and 1.5 releases were so "hasty", though
>>> (and thanks for that) we have now Axel who works hard to handle l10n
>>> concerns.
>> I recall 1.5 to be worse in terms of process, though help pretty much
>> runs through my parade like a truck driven by the governor of California.
>
> Maybe I don't remember this correctly, but for 1.5 the pref window
> changes were documented in en-US help way sooner than for 2.0.
> I even don't remember any problems with 1.5 help that pl would suffer,
> though I am sure I will remember the 2.0 help situation for a long time.
A good part of the reason for this is that Steffen and I were less clear about the deadlines we had to hit, so we acted conservatively in getting the prefwindow done early. This time around Steffen has been somewhat more busy, and I was closer to things and thus knew a bit more about the necessary deadlines. It also didn't help that I was pretty much awol for quite a while on the Help front with only small effort occurring a few places over the summer and the one last concerted push. If you look at the quantity of actual Help changes from 1.5->2.0, I'd be surprised if you found more than a handful which weren't "fix to match changed UI" bugs. (Heck, this is even true to a lesser extent for 1.0->1.5 -- the last major user-facing Help changes to actual content occurred for 1.0, for similar reasons.) A last problem was that the bug was not assigned to Steffen or me but rather to another person who hadn't been involved with Help docs before, and while the patch he produced w
as invaluable in helping me create the "final" patch (mod tweaks), it was also produced a bit later than had been promised or was desired.
I'd really like to be able to get more positive changes done on Help docs, but classes and homework suck up a large portion of my time. Another "problem" depending how you look at it is that as I've delved deeper into the Mozilla codebase, I find more and more interesting code to explore[0], bugs to fix[1], and features to write[2]. [3] This is *not* necessarily that I find the other code more interesting, more difficult, or more satisfying in the long run -- it's that it's *fun* to hit my head against new problems, to learn how to adapt my thinking to code implementing different things, and to thus become better at jumping into new and alien code in the future. Long term, I have no intention of ending my involvement in Help, but given the abundant technical challenges in the Mozilla project, it's easier to spread myself out perhaps more than is good for every single thing I'm doing.
So there you have it, from my point of view -- lots interesting things for me to do, too little time for me to do everything, lack of time for the few other Help documenters to get stuff done, (in this case) too much foreknowledge of the release process, and over-reliance for the prefwindow patch upon a person not part of the usual group of Help documenters.
Jeff
0. Most recently, the xpcshell-simple test harness, pointed out indirectly by darin while working on bug 302348
1. cf. bug 345666, filed and fixed due to bug 345700, which came about partly as a result of being pointed to xpcshell-simple
2. cf. bug 342877, which came about after being pointed at the netwerk tests that contain a bare-bones HTTP server and finding it lacking but so potentially useful a tool for writing unit tests, embedding in developer extensions, etc.
3. I could go on for awhile here with all sorts of cool things I've found/written/tested/documented/etc., but I'll stop ;-)
--
Rediscover the Web!
http://snurl.com/get_firefox
Reclaim Your Inbox!
http://snurl.com/get_thunderbird
Jeff Walden
> What makes help take so long? I've just been reviewing a help content
> patch (the first I really ever looked at closely), is it the technical
> complexity of search/toc/xhtml files? Or is that full-text translation
> does require more or less different language genes? What else?
From my point of view, long text strings require a considerably greater degree of coherency and consistency than the short strings which make up most of the Firefox UI. The use of RDF also doesn't really help things (tho I'm not sure what a good replacement is, given that the way our docs work internally requires at least a tree-like API and probably a DAG if not graph API). A related issue is keeping rdf:IDs matched up correctly, which even en-US didn't completely manage -- that's a hard problem when you're changing the world.
Jeff
Jeff Walden
> The mere translation job of help files is not difficult in itself. What
> takes lot of time is to check that every described item has the same
> label in the UI and in the Help section.
Good point. I allude to this in one of my last few posts, tho not quite explicitly.
> That's why we chose for fr to use DTD's entities to stay synch, so that
> in case of fixing a typo or rewording something in a dtd file, it
> "updates" at the same time help file;
We may eventually move to this with en-US help sometime; there's a bug filed on it which at least at the time was a good goal. I don't remember if I've had any recent experiences which would suggest this is bad idea. (Integrating in the RDF might be problematic, but I'm not 100% sure of that.)
> and if an entity disappears or is renamed, we've got a beautiful red
> line, so that, we know help is not up to date.
Aside: XHTML's yellow screen of death is an invaluable help to me with working on en-US help -- catch the stupid mistakes automatically.
> It might have been easier to handle for localizers if, for instance,
> this huge patch (+- 584/474) had been sliced into several little
> ones, like one for each prefs panel for instance (or even tab in
> the panel), as the diffs would have been easier to read.
I honestly don't think your job would have been significantly easier, except perhaps psychologically. Then again, I've never had to do what you've done, except inasmuch as the reviewing I had to do for bug 279506 (the previous prefwindow docs rewrite) was of a similar magnitude. (And yes, the psychological impact is arguably considerable in such cases. :-\ )
Robert Kaiser
> Cédric Corazza wrote:
>> That's why we chose for fr to use DTD's entities to stay synch, so that
>> in case of fixing a typo or rewording something in a dtd file, it
>> "updates" at the same time help file;
>
> We may eventually move to this with en-US help sometime; there's a bug
> filed on it which at least at the time was a good goal. I don't
> remember if I've had any recent experiences which would suggest this is
> bad idea. (Integrating in the RDF might be problematic, but I'm not
> 100% sure of that.)
Integrating in the RDF should even work, it's all XML after all...
Anyways, we've done this for at least the pref panel titles in
SeaMonkey, help uses them from DTDs, and I think it works fine. Giacomo
Magnini, who is doing lots of our help work (and is a localizer himself)
can probably tell you more about this though, as he has done that work,
IIRC.
Robert Kaiser
Giacomo Magnini
> Anyways, we've done this for at least the pref panel titles in
> SeaMonkey, help uses them from DTDs, and I think it works fine. Giacomo
> Magnini, who is doing lots of our help work (and is a localizer himself)
> can probably tell you more about this though, as he has done that work,
> IIRC.
I'll add my 2 cents here.
Yes, there is a bug open since a long time about using entities for UI
elements in the help docs (actually, IIRC, there should be 2 bugs, one
for FF and one for SM). At the time, I took a look at the conversion and
I, and many others, pointed out some problems:
1) many preference panels don't have a unique name (hence the bug which
solved most of the problems at the time, except for DOMI: blame the
in-tree localizations here).Nowadays, there may be even a few more of
such duplicated dialog/window/panel names (thinking about reporter,
xforms, and all of the recent additions to the code base). I guess that
even many elements not in pref panels do have the same name (eg:
browseButton), and having them in the same help doc will pose additional
problems.
2) many elements are a mix of dtd and properties entries: using dtd's is
a no brainer, but properties are a bit different, IIRC: XBL? Stefan
Hermes may know more about this.
3) using entities in rdf may look awesome, but it will horribly break
for localized versions (think about the alphabetical order in
help-index1 with an entity that changes the initial letter between en-US
and localized version -> nothing is shown!).
The rdf files are also the rock on the road to install only the docs for
the chosen components, skipping the rest, in SM.
And they are preventing also the use of entities for branding purposes
for the same problem as in 3).
And again, rdf files are also a pain to mantain and keep up to date in
the localized versions (at least for Italian), when you have to move
stuff all around to preserve alphabetical order.
Did I say that rdf files are a pain? Probably not enough... ;)
Now it's a bit late for remembering more about these issues or to look
at bug numbers. If asked, I'll add all the relevant ones.
Ciao, Giacomo.
Stefan Hermes
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>
>
Bug 305142 (https://bugzilla.mozilla.org/show_bug.cgi?id=305142) is
currently blocking the use of entities from composer/messenger/mailnews
etc in the help doc.
/Stefan
Marek Stępień
> Late response to a rather old email (possibly more to come in this
> thread in the next day-ish), but better than none, I hope...
> IE7 shipped yesterday,
Yup. So I was wrong about it. I just wonder how did some of Mozilla guys
know that IE 7 would be released so early, as the so-called common
knowledge was that it's gonna be in 2007. ;-)
> I'm curious -- in retrospect, was the "do it for RC2" approach truly
> insufficient?
It depends. It was probaly sufficient for tier-1 and most of the tier-2
locales, but only recently we've found showstopper bugs in some of the
other locales (be, pa-IN), moving them to 2.0.0.1.
For pl it was good enough (however, between RC2 and RC3 we found some
minor, not release-blocking glitches, but couldn't check the
patches in for RC3).
Axel Hecht
You're confusing using entities in RDF/XML files here with moving those
files over into content. Those two are separate questions.
> The rdf files are also the rock on the road to install only the docs for
> the chosen components, skipping the rest, in SM.
> And they are preventing also the use of entities for branding purposes
> for the same problem as in 3).
> And again, rdf files are also a pain to mantain and keep up to date in
> the localized versions (at least for Italian), when you have to move
> stuff all around to preserve alphabetical order.
The problem is that maintaining an index is hard work in itself. Writing
it down in RDF/XML is just cumbersome.
Note that, as Jeff pointed out in the bug referenced by Stefan's answer
ages ago, using RDF/XML files for the help indexes actually helps in
tearing the apart for SeaMonkey.
Axel
Axel Hecht
> Late response to a rather old email (possibly more to come in this
> thread in the next day-ish), but better than none, I hope...
>
>
> Marek Stępień wrote:
>> But IE7 isn't shipping in November, is it?
>
> IE7 shipped yesterday, and we ship a few days later, by my time zone.
> (Not that I'm well-informed enough to know whether this timing is good
> or bad, but since this question can now be answered...)
>
>
>> Well, certainly pl users will not want to wait a week for a fix in zh-CN
>> nor vice versa, but we have lots of fixes for many of the locales, not
>> just one.
>
> I'm curious -- in retrospect, was the "do it for RC2" approach truly
> insufficient? I suppose it was a gamble that there'd be an RC2, but I
> for one would have taken and will continue to take that bet *any* day,
> for *any* Firefox release, regardless what anyone says about RCs being
> completely, utterly, totally release-worthy.
Yes. Just to be blunt. That's not you to blame, though, there seems to
be different opinions on whether user documentation is a Firefox feature
or not.
Just assuming for a minute it is, 'feature-scale' changes to help should
have been done by B2, IMHO, and pref-window docs is the one we had here,
I guess. My personal opinion is that we shouldn't have to change the TOC
after string freeze.
I know that this is a bigger fish to fry, sounds like a good thing to
chat about in MV in November?
Thanks for the insight here.
I do agree that we should do some in-depth work on help again (I can't
really see us go without end-user docs, like, really). Do you have
proposals on how to get some traction here? Maybe pull in more community
resource, both for the en-US version and for the localized versions?
If so, it might be a good idea to maybe start a new thread on both
m.d.a.firefox and m.d.l10n on that.
My premise here is that help should be done for release. I see some
value in having end-user docs on the web, but hardly any reason to not
have them in the app. Download size should really be a minor item here,
for sure, and it might be more work to separate out the hosted vs the
shipped parts than it's worth in the end.
Axel
Giacomo Magnini
> The problem is that maintaining an index is hard work in itself. Writing
> it down in RDF/XML is just cumbersome.
Once upon a time (NS era) there was a tool for generating those indexes:
I've never seen it, but I know it exist(ed) based on many comments in
bugs. Oh, yes, it was the time when IDX and SDX were plaguing the help
docs...
Writing an index in any format is a pain if there is no tool for such
work. Double the pain if there is nothing you can use to generate an
index format in the first place. Ok, I'm only whining here, instead of
suggesting a solution. But it should be clear that the solution is not
replacing rdf with something else, or adding more bandaids to current
rdf files; it's a matter of going to the source of the problem, not its
symptoms.
Ciao, Giacomo.
Ricardo Palomares Martinez
> Axel Hecht ha scritto:
>> The problem is that maintaining an index is hard work in itself.
>> Writing it down in RDF/XML is just cumbersome.
>
> Once upon a time (NS era) there was a tool for generating those indexes:
Yeah, it existed. I later wrote myself a Perl script that, using id
attributes in HTML headings, was more or less able to create the TOC
RDF (I had one that created automatically glossary.rdf).
The problem with that script was that the heading content (the titles
themselves) needed to be short, or at least meaningful enough in their
very first words, so users could distinguish between them in the TOC.
Also, it worked with Mozilla Suite help content, but I'm not really
sure if it would make it for Firefox.
But it's clear that, if an attribute could be used in XHTML elements
in such a way that both en-US and the rest of languages could generate
the RDFs automatically from the help content, it would be wonderful.
BTW, Calendar Help project (http://calendarhelp.mozdev.org/build.html)
has an extension that is able to build automatically indexes for both
en-US and translations, although I don't know it they quirk in any way
the XHTML specs.
Jeff Walden
>> I'm curious -- in retrospect, was the "do it for RC2" approach truly
>> insufficient? I suppose it was a gamble that there'd be an RC2, but I
>> for one would have taken and will continue to take that bet *any* day,
>> for *any* Firefox release, regardless what anyone says about RCs being
>> completely, utterly, totally release-worthy.
>
> Yes. Just to be blunt.
I think you misunderstand. What I want to know is whether localizers had bugs they would have liked to fix but could not fix for RC2 which they would definitely have fixed had the prefwindow been finished earlier. (I'm not counting nice-to-haves, because those never go away completely; I'm counting factual incorrectness, incompleteness, grammatical errors and misspellings induced by haste of translation, etc. and not "this [perhaps-]hastily-translated text would be better if worded this way".)
We can all agree that still localizing by RC2 is extremely suboptimal, but I want to know whether it had any meaningful impact on the final product as shipped.
> Just assuming for a minute it is, 'feature-scale' changes to help should
> have been done by B2, IMHO, and pref-window docs is the one we had here,
> I guess. My personal opinion is that we shouldn't have to change the TOC
> after string freeze.
One of these days I'm going to understand why Help is still a vaguely optional component of localizations and of Firefox. Maybe.
> I know that this is a bigger fish to fry, sounds like a good thing to
> chat about in MV in November?
Yeah, indeed. I have an idea or two on how to make Help/etc. easier which I need to think about a bit first.
Jeff
João Miguel Neves
> I think you misunderstand. What I want to know is whether localizers had bugs they would have liked to fix but could not fix for RC2 which they would definitely have fixed had the prefwindow been finished earlier. (I'm not counting nice-to-haves, because those never go away completely; I'm counting factual incorrectness, incompleteness, grammatical errors and misspellings induced by haste of translation, etc. and not "this [perhaps-]hastily-translated text would be better if worded this way".)
>
windows changes and the help changes made us run for RC1 in a way that
everything stopped for a few days afterwards because people needed to
rest. For RC2 we got a lot of bug fixes, but we still missed patches for
long known bugs (like pref window width) and basic stuff like a "null"
where a brand name should be in the detection of the default browser.
Best regards,
João Miguel Neves