Need l10n QA on Bug 109481

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Need l10n QA on Bug 109481

Jason Barnabe (np)
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?
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Pavel Franc
> 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.

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">


_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA - Czech strings

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">
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Benjamin Smedberg
In reply to this post by Jason Barnabe (np)
Jason Barnabe (np) wrote:
> 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?

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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Axel Hecht
Benjamin Smedberg wrote:

> Jason Barnabe (np) wrote:
>> 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?
>
> 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.

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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Andras Timar
Axel Hecht írta:
>
> 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.
>
Why is a localised component with a few unlocalised string worse than a
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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Pavel Franc
> 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

> 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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Andras Timar
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.

>
>> 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.
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Robert Kaiser
In reply to this post by Axel Hecht
Axel Hecht schrieb:
> 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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Axel Hecht
In reply to this post by Andras Timar
Andras Timar wrote:

> 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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Axel Hecht
In reply to this post by Robert Kaiser
Robert Kaiser wrote:

> Axel Hecht schrieb:
>> 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).

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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Axel Hecht
In reply to this post by Pavel Franc
Pavel Franc wrote:

>> 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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Robert Kaiser
In reply to this post by Axel Hecht
Axel Hecht schrieb:

> Benjamin Smedberg wrote:
>> Jason Barnabe (np) wrote:
>>> 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?
>>
>> 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.
>
> 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.

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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Axel Hecht
Robert Kaiser wrote:

> Axel Hecht schrieb:
>> Benjamin Smedberg wrote:
>>> Jason Barnabe (np) wrote:
>>>> 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?
>>>
>>> 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.
>>
>> 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.
>
> 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.

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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Axel Hecht
In reply to this post by Jason Barnabe (np)
Just a note in general, don't bother about what actually happens here or
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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Need l10n QA on Bug 109481

Robert Kaiser
Axel Hecht schrieb:
> Just a note in general, don't bother about what actually happens here or
> 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.

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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n