Problem with Serbian localization when click on "check for updates"

RESOLVED FIXED

Status

--
major
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: kapetance, Assigned: filmil)

Tracking

unspecified
x86
Windows XP
Dependency tree / graph

Firefox Tracking Flags

(status1.9.1 .2-fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; sr; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; sr; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)

With Serbian translation, when I click on Check for updates, I get a window with folowing

Грешка у рашчлањавању ИксЕмЕла (XML): неодређени унос
Место: chrome://mozapps/content/update/updates.xul
Ред 46, колона 52:    <label id="noUpdatesAutoEnabled" hidden="true">&noupdatesautoenabled.intro;</label>
---------------------------------------------------^

and no update check. 
This was problem in all betas and RCs

Reproducible: Always

Steps to Reproduce:
1.Firefox 3.5 in Serbian
2.Помоћ > Провера доградњи (on English "check for updates menu in help menu"



Expected Results:  
I should open update checking box.
(Reporter)

Updated

9 years ago
Version: unspecified → 3.5 Branch
(Reporter)

Updated

9 years ago
Summary: Problem with Serbian localization when click on "check for updatesĆ → Problem with Serbian localization when click on "check for updates"

Updated

9 years ago
Component: General → Localization
Product: Firefox → Core
QA Contact: general → localization
Version: 3.5 Branch → 1.9.1 Branch

Comment 1

9 years ago
Just pasting this here for whoever looks at this bug to save them some time

http://mxr.mozilla.org/l10n-mozilla1.9.1/source/sr/toolkit/chrome/mozapps/update/updates.dtd#10

<!ENTITY noupdatesautoenabled.intro "Нема нових доградњи.  &brandShorName; ће периодични проверавати доградње.">
Keywords: qawanted

Comment 2

9 years ago
Sasa, could you please confirm if this happens in Firefox's safe mode?
(Reporter)

Comment 3

9 years ago
(In reply to comment #2)
> Sasa, could you please confirm if this happens in Firefox's safe mode?

Same problem in Safe mode

Updated

9 years ago
Component: Localization → sr / Serbian
Product: Core → Mozilla Localizations
QA Contact: localization → sr
Version: 1.9.1 Branch → unspecified

Comment 4

9 years ago
Same for me. Marking this as new, `cos it`s confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

9 years ago
Severity: normal → major
Flags: blocking1.9.1.1?
Axel, this looks really identical to bug 498753 for [mk]. :( Should we stop offering updates for this locale and remove the installers from the ftp server to avoid that more people are affected?
Keywords: qawanted
the entity is  missing a T &brandShorName; should be &brandShortName;
Should we as an emergency measure remove Serbian from product-details and put a redirect to en-US from the Serbian download page?
After talking to Seth on the phone, I updated product-details to remove Serbian and redirected the mozilla.com/sr/ page to en-US.

r29254 , r29253 and then r29257 (to remove completely Serbian and Macedonian from the main dl box)
Henrik, thanks for the heads up. As comment #1 and comment #6 noted this is due to updates.dtd using &brandShorName which is incorrect vs. &brandShortName.
http://mxr.mozilla.org/l10n-mozilla1.9.1/source/sr/toolkit/chrome/mozapps/update/updates.dtd#10
(In reply to comment #0)
> With Serbian translation, when I click on Check for updates, ...

It's the same for background update checks if Firefox is set to "Ask me what we want to do", and I'd expect the same for background check + prompt when ready to apply.

> This was problem in all betas and RCs

Please file a bug as soon as you notice a problem, thanks.

In fact, the bogus entity was introduced in 
 http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/sr/rev/76811180f829
and is present in b3 onwards.

I'll work on pulling the major update path from 3.0.11 to 3.5 final.
(Assignee)

Comment 11

9 years ago
Ok, I am back home from work.  Let's patch this...

Please stand by until a patch arrives.
(Assignee)

Comment 12

9 years ago
Created attachment 386435 [details] [diff] [review]
Fixes the bogus entity.
(Assignee)

Updated

9 years ago
Attachment #386435 - Flags: approval1.9.0.13?
Attachment #386435 - Flags: approval1.9.0.12?
(Assignee)

Updated

9 years ago
Assignee: nobody → filmil
(In reply to comment #10)
> In fact, the bogus entity was introduced in 
>  http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/sr/rev/76811180f829
> and is present in b3 onwards.
Except sr only shipped from b5 onwards.

I pulled (just like mk in bug 501344)
* Builds from the releases dir
* live 3.0.11 snippets for beta/release channels, and betatest/releasetest (backed up to aus-staging:~cltbld/3.0.11-3.5-mu-pulled-sr/)
(Assignee)

Comment 14

9 years ago
Hi.  The fix is in, can someone r+ it?

What is the plan to bring Serbian ff back to downloads?
Attachment #386435 - Flags: review?(l10n)
Attachment #386435 - Flags: approval1.9.0.13?
Attachment #386435 - Flags: approval1.9.0.12?
Comment on attachment 386435 [details] [diff] [review]
Fixes the bogus entity.

There's no error in Fx3.0, see
  http://mxr.mozilla.org/l10n/source/sr/toolkit/chrome/mozapps/update/updates.dtd#13 
so the approval1.9.0.1x flags aren't appropriate. You'd want the (non-existent) approval-1.9.1.1, setting r? on Axel instead.
(Assignee)

Comment 16

9 years ago
FWIW, I tested the patch on my local FF 3.5 and it seems to work well.
Can we confirm no other locales see the same problem?
(Assignee)

Comment 18

9 years ago
(In reply to comment #17)
> Can we confirm no other locales see the same problem?

Not sure what you mean.  This is a fix only for the Serbian locale.
(In reply to comment #17)
> Can we confirm no other locales see the same problem?
Looks like he mistyped &brandShortName for Thunderbird as well
http://mxr.mozilla.org/l10n-central/source/he/mail/chrome/messenger/accountCreation.dtd#39

As for other mistyping of &brandShortName or other entities it appears that l10n doesn't have any scripts in place to try to detect these types of mistakes.
Attachment #386435 - Flags: review?(l10n) → review+
Comment on attachment 386435 [details] [diff] [review]
Fixes the bogus entity.

r=me.

We actually don't need the review for things like this [1] now that we're on hg. Filip, please land this fix on the 1.9.1 branch and l10n-central and let us know (for example here in this bug) about the landing and the new changeset from which we should build. We will then update the l10n-changesets accordingly.

([1] Note that any changes to region.properties or searchengines still require a review)

Comment 21

9 years ago
(In reply to comment #19)
> As for other mistyping of &brandShortName or other entities it appears that
> l10n doesn't have any scripts in place to try to detect these types of
> mistakes.

Filip, if you want to avoid these issues, have a look at pofilter from the Translate Toolkit:
http://translate.sourceforge.net/wiki/toolkit/pofilter

The l10n infrastructure shouldn't allow a translation to break the product, but while it does, this QA tool should find all issues that can break the product. It would have avoided this and the Macedonian issue.

The critical tests with  pofilter --mozilla  are printf, variables and xmltags.
Reviewing these tests should catch stuff like this. (XML entities are tested as part of the "variables" test.)

Some of the other tests are more for cosmetic things, and there could be some
false positives. It might be good to review them anyway.

So to test:
(assuming sr_po contains all your PO files of the sr l10n files)
pofilter --mozilla --test=printf --test=variables --test=xmltags  sr_po
sr_filter

sr_filter/ will contain the suspicious translations to review.
(Assignee)

Comment 22

9 years ago
(In reply to comment #20)
> (From update of attachment 386435 [details] [diff] [review])
> r=me.
> 
> We actually don't need the review for things like this [1] now that we're on
> hg. Filip, please land this fix on the 1.9.1 branch and l10n-central and let us
> know (for example here in this bug) about the landing and the new changeset
> from which we should build. We will then update the l10n-changesets
> accordingly.
> 

Landed as: 878a83718455 for 1.9.1
> ([1] Note that any changes to region.properties or searchengines still require
> a review)
(Assignee)

Comment 23

9 years ago
(In reply to comment #21)
> Filip, if you want to avoid these issues, have a look at pofilter from the
> Translate Toolkit:
> http://translate.sourceforge.net/wiki/toolkit/pofilter
> [...] Reviewing these tests should catch stuff like this. (XML entities are tested as
> part of the "variables" test.)

Friedel, thanks for the tip.

I tried it immediately, as I don't really want my translations to contain critical errors that go undetected into the release.

However, I also don't think the output of the program is useful in its current form.  

At least for me, it generates a lot of files buried in subdirs, which must be checked manually.  This is about as painful and error-prone as hand-checking the original files.  The check must be fully automated, and either give a green light, or a red light as output.

You could make pofilter output more useful if you split the 'QA testing' functionality of pofilter (which produces files for manual review), and the 'unit test' pofilter, which looks for problems, and if it finds one, stops with an error, pointing at the problem text.  

The latter would be a very useful addition to my moz2po-based workflow, and I think others would find it useful too.
(Assignee)

Updated

9 years ago
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
(Assignee)

Updated

9 years ago
Blocks: 501892

Updated

9 years ago
Blocks: 501391
I have made Firefox 3.5(sr) available for download from my server, intended for downloads from Serbian Community site. So, can you predict when will this push happen, so I can publish appropriate notification for all our users?

Comment 25

9 years ago
Milos, please pull those ASAP. Really.

You're just confusing people with builds that they can't update.
(In reply to comment #25)
> Milos, please pull those ASAP. Really.
> 
> You're just confusing people with builds that they can't update.

Don`t worry, I did. I`ve left download image, `cos I`m afraid that I may discourage users to use new version, but I`ve created JScript alert onlclick to say that downloads are disabled temporarily and that we`ll try to fix this soon.
Sorry for bugging, but I got many complaints from users not being able to download localized Firefox 3.5 (Serbian). As I can see here, this patch is good, so we only wait for a push to happen. Can we at least have an estimate on when will push happen, please?
It is most unusual to redo a locale after a release has shipped, and we're trying to decide what the best way forward is. There is no estimate at this point.
Did this fix land on the Serbian 1.9.1 branch?
(Assignee)

Comment 30

9 years ago
(In reply to comment #29)
> Did this fix land on the Serbian 1.9.1 branch?
See:
https://bugzilla.mozilla.org/show_bug.cgi?id=501596#c22
blocking1.9.1: --- → needed
status1.9.1: --- → wanted
Flags: blocking1.9.1.1?
blocking1.9.1: needed → ---
status1.9.1: wanted → .2-fixed
This works for me.
You need to log in before you can comment on or make changes to this bug.