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.
Summary: Problem with Serbian localization when click on "check for updatesĆ → Problem with Serbian localization when click on "check for updates"
Component: General → Localization
Product: Firefox → Core
QA Contact: general → localization
Version: 3.5 Branch → 1.9.1 Branch
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; ће периодични проверавати доградње.">
Sasa, could you please confirm if this happens in Firefox's safe mode?
(In reply to comment #2) > Sasa, could you please confirm if this happens in Firefox's safe mode? Same problem in Safe mode
Component: Localization → sr / Serbian
Product: Core → Mozilla Localizations
QA Contact: localization → sr
Version: 1.9.1 Branch → unspecified
Same for me. Marking this as new, `cos it`s confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
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?
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.
Ok, I am back home from work. Let's patch this... Please stand by until a patch arrives.
(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/)
Hi. The fix is in, can someone r+ it? What is the plan to bring Serbian ff back to downloads?
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 approval18.104.22.168x flags aren't appropriate. You'd want the (non-existent) approval-22.214.171.124, setting r? on Axel instead.
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?
(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.
Comment on attachment 386435 [details] [diff] [review] Fixes the bogus entity. r=me. We actually don't need the review for things like this  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. ( Note that any changes to region.properties or searchengines still require a review)
(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.
(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  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 > ( Note that any changes to region.properties or searchengines still require > a review)
(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.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
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?
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?
(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
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.