Need l10n QA on Bug 109481
Jason Barnabe (np)
Bug 109481 adds some strings in DOM Inspector. Adding just the English
strings makes the compile fail, so can't do that. Axel didn't like
adding English strings to the other locales.
What should be done?
Pavel Franc
What about posting the strings and their translation here. Doing so we
can also fix strings for bug
https://bugzilla.mozilla.org/show_bug.cgi?id=264748 that has the same
problem - no strings for all locales.
Pavel
------------------
Bug 109481:
<!ENTITY mnInspectDocument.label "Inspect Document">
<!ENTITY mnInspectDocument.accesskey "D">
<!ENTITY cmdToggleChrome.label "Chrome">
<!ENTITY cmdToggleChrome.accesskey "C">
inspectWindow.noDocuments.message = (None)
Bug 264748:
<!ENTITY dom.label "DOM Nodes">
<!ENTITY stylesheets.label "Stylesheets">
<!ENTITY domNode.label "DOM Node">
<!ENTITY boxModel.label "Box Model">
<!ENTITY xblBindings.label "XBL Bindings">
<!ENTITY styleRules.label "CSS Style Rules">
<!ENTITY computedStyle.label "Computed Style">
<!ENTITY jsObject.label "Javascript Object">
Pavel Franc
> Bug 109481:
> <!ENTITY mnInspectDocument.label "Inspect Document">
> <!ENTITY mnInspectDocument.accesskey "D">
> <!ENTITY cmdToggleChrome.label "Chrome">
> <!ENTITY cmdToggleChrome.accesskey "C">
>
> inspectWindow.noDocuments.message = (None)
<!ENTITY mnInspectDocument.label "Prozkoumat dokument">
<!ENTITY mnInspectDocument.accesskey "d">
<!ENTITY cmdToggleChrome.label "Chrome">
<!ENTITY cmdToggleChrome.accesskey "C">
inspectWindow.noDocuments.message = (Žádný)
> Bug 264748:
> <!ENTITY dom.label "DOM Nodes">
> <!ENTITY stylesheets.label "Stylesheets">
> <!ENTITY domNode.label "DOM Node">
> <!ENTITY boxModel.label "Box Model">
> <!ENTITY xblBindings.label "XBL Bindings">
> <!ENTITY styleRules.label "CSS Style Rules">
> <!ENTITY computedStyle.label "Computed Style">
> <!ENTITY jsObject.label "Javascript Object">
<!ENTITY dom.label "Uzly DOM">
<!ENTITY stylesheets.label "Styly">
<!ENTITY domNode.label "Uzel DOM">
<!ENTITY boxModel.label "Vlastnosti boxu">
<!ENTITY xblBindings.label "XBL vazby">
<!ENTITY styleRules.label "Pravidla CSS">
<!ENTITY computedStyle.label "Výsledné styly">
<!ENTITY jsObject.label "Objekty Javascriptu">
Benjamin Smedberg
We should either add the English string to all locales or remove all the
non-English locales from
http://lxr.mozilla.org/mozilla/source/extensions/inspector/resources/Makefile.in#47
until the l10n is complete.
--BDS
Axel Hecht
Go through the list of locales in CVS and get the owners on CC and
invite them to provide patches.
http://wiki.mozilla.org/L10n:Localization_Teams has the owners.
After a grace period, break the locales by removing the un-used
entities, but don't add the new ones, instead, remove the locales from
Makefile.in (rather, comment them out, mentioning the bug number) and
file bugs on the remaining locales.
Axel
Andras Timar
>
> After a grace period, break the locales by removing the un-used
> entities, but don't add the new ones, instead, remove the locales from
> Makefile.in (rather, comment them out, mentioning the bug number) and
> file bugs on the remaining locales.
>
completely unlocalised component? E.g. the developers of the calendar
component used to add the new English strings to all locales and remove
the unnecessary string from all locales. Could you please explain your
decision.
Thanks,
Andras
Pavel Franc
> completely unlocalised component?
- it is confusing for user
- it looks unprofesionall
- it is a first step to produce messy localization
> component used to add the new English strings to all locales and remove
> the unnecessary string from all locales.
And the result is that the localization of calendar is totally broken
for most of the locales in calendar.
Pavel
Andras Timar
>> Why is a localised component with a few unlocalised string worse than a
>> completely unlocalised component?
>
> - it is confusing for user
> - it looks unprofesionall
> - it is a first step to produce messy localization
You may be right but this is how gettext based software and
OpenOffice.org works. They fall back to English when a localised string
is not available. This is not unusual at all. Mozilla does not have this
fallback mechanism and it seems that developers do not even want to (or
are not allowed to) imitate it, although it could reduce the
administrative overhead.
>
>> component used to add the new English strings to all locales and remove
>> the unnecessary string from all locales.
>
> And the result is that the localization of calendar is totally broken
> for most of the locales in calendar.
This is not true. The localisation of the calendar is broken, because
the developers stopped to maintain the localisations. Probably they
thought that transition to l10n CVS would not take so long. Their method
worked perfectly in the past.
Robert Kaiser
> Go through the list of locales in CVS and get the owners on CC and
> invite them to provide patches.
> http://wiki.mozilla.org/L10n:Localization_Teams has the owners.
Well, that only lists toolkit, browser, and mail owners, not owner of
other components, which may be different.
In case of German, for example, I'm not even listed on the page, but I'm
owning reporter, inspector, calendar localizations for German (as well
as others that aren't yet in CVS).
Robert Kaiser
Axel Hecht
> Pavel Franc írta:
>>> Why is a localised component with a few unlocalised string worse than a
>>> completely unlocalised component?
>> - it is confusing for user
>> - it looks unprofesionall
>> - it is a first step to produce messy localization
>
> You may be right but this is how gettext based software and
> OpenOffice.org works. They fall back to English when a localised string
> is not available. This is not unusual at all. Mozilla does not have this
> fallback mechanism and it seems that developers do not even want to (or
> are not allowed to) imitate it, although it could reduce the
> administrative overhead.
>
For most parts of our localization, we have a tracking mechanism to see
if all strings are localized.
By adding english strings, we bork that, and that we don't add crap to
other people's code is good practice, IMHO.
Note that we will remove unfinished localizations from the Makefile, and
thus from the build whichever way we go, thus not adding english stuff
is just as good as not adding anything, but with compare-locales, you
can at least check what should be added.
Axel
Axel Hecht
And Abdulkadir knows. There's no reason for inspector folks to bother
about the details, and german is very special in this case. As you can
actually commit a change, and Abdulkadir cannot.
Axel
Axel Hecht
>> https://bugzilla.mozilla.org/show_bug.cgi?id=109481
>>
>> Bug 109481 adds some strings in DOM Inspector. Adding just the English
>> strings makes the compile fail, so can't do that. Axel didn't like
>> adding English strings to the other locales.
>>
>> What should be done?
>
> What about posting the strings and their translation here. Doing so we
> can also fix strings for bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=264748 that has the same
> problem - no strings for all locales.
>
I don't buy the benefit of having localization done in newsgroups in
favour of doing in in bugzilla attachements. Providing a patch there is
easy, and can be done with anyonymous access just as well.
As in other cases, I advise DOMI folks to prepare a patch with a minimal
set of locales ready and then file follow-up bugs.
Axel
Robert Kaiser
I would prefer if we handle such cases a bit differently than like it's
done currently. I wonder why the compile fails when not adding the
strings to the locales, that shouldn't happen, the only failure should
be compare-locales and that shouldn't be fatal in such a build IMO.
When that would be true, we could just check in the en-US string with a
notification to localizers in here, and then we could pull the english
strings as usual and use our tools to build a localized version and
check it in.
With the current situation, I have to apply the patch to my local tree
to use the tools on the result to create a patch, and I think that's not
something other localizers that use tools would like to do.
Robert Kaiser
Axel Hecht
Well, we won't build a broken locale, come rain or shine. I don't care
if a localizer uses the tools we offer or not here, it's just that once
a locale has to catch up, it's much easier to verify the patch if we
removed old entities and do not add new ones.
Axel
Axel Hecht
not.
I have good hopes that we will have extension language packs for fx2,
and then all of this will be mute, and l10n of inspector is going to
move back to bed, err, /l10n. I'd be way suprised at least if we
wouldn't come up with inspector being our test bunny here.
Axel
Robert Kaiser
That would be good, as it really would ease all that stuff quite a lot.
And the en-US build won't break just because some localizer doesn't jump
on every change done elsewhere.
Robert Kaiser