498753 - [mk] Check for updates dialog broken

Status: RESOLVED FIXED

(Mozilla Localizations :: mk / Macedonian, defect)

Description

[Axel Hecht [:Pike]]

There is an XML parsing error in the "Check for updates" dialog in the Macedonian 3.5 localization.

Damian reported that in the newsgroup, that's worth filing a bug.

The culprit are two refences to &BrandShortName; in updates.dtd.

I'm going to land a bustage fix right now, as we're respinning anyway.

I did a grep on my local clone, that's the only occurance I found for BrandShortName.

Comment 1

[Axel Hecht [:Pike]]

Pushed http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/mk/rev/e92583157876, please pull your 1.9.1 repo before making further changes.

This still needs landing on the l10n-central/mk repo.

Comment 2

[Robert Strong (they/them - no direct email)]

Axel, is there anyway that an l10n verification script could be written to detect these types of l10n bugs?

Comment 3

[Axel Hecht [:Pike]]

Tough. All XML libraries that I checked make it really hard to detect entity references, and we use entity references from other DTD files without a clear idea where they're coming from. I.e., just looking at a single DTD file, you can't really tell whether all XML files including it also include brand.dtd in the right way. There could probably heuristics to check if a string parses as an XML fragment, and if so, which entities it imports and if it's a non-standard XML one if it'd be included in the en-US equivalent. Which would still cause false positives for brandShortName vs brandFullName. And it'd require to write an XML fragment parser, AFAICT. I haven't found any lib that supports this usecase.

Comment 4

[Friedel Wolff]

(In reply to comment #2)
> Axel, is there anyway that an l10n verification script could be written to
> detect these types of l10n bugs?

Robert, we have been using pofilter for years and never get these errors. Check http://translate.sourceforge.net/wiki/toolkit/pofilter

It doesn't clean your room and bring you coffee, but it does seem to catch almost all the translations that could make the software crash. In this case it would be easy to spot that the translation is using an entity that was not present in the en-US. I guess there could be some valid cases with entities that wasn't used in the en-US, but it is far more useful to go over a few false positives and avoid releasing crashing browsers, in my opinion. At least in my team we never use entities that was not used in the en-US, perhaps with the exception of '.

The critical tests with pofilter --mozilla   are printf, variables and xmltags. That should catch stuff like this in many cases.

Some of the other tests are more for cosmetic things, and there could be some false positives.

So to test:
Install the Translate Toolkit
moz2po -t en-US  mk  mk_po
pofilter --mozilla --test=printf --test=variables --test=xmltags  mk_po mk_filter

mk_filter/ will contain the suspicious translations to review.

Comment 5

[Robert Strong (they/them - no direct email)]

Friedel, can it or a mozilla/home grown version of it be added to our build system to detect these types of bugs so if a bad l10n patch lands it is detected by the l10n tinderboxen? From Axel's response it doesn't appear to be possible.

Comment 6

[Axel Hecht [:Pike]]

This bug isn't really the best place to discuss the reliability of our various tools. Automated runs of those tests (there's dynamis' tool, too, something from the French team or Italian?) would be nice, but in the end, we need runtime test coverage, and that's the next big thing on my radar. Dynamis actually runs his tool on all locales by hand and posts the results to .l10n as an intermediate step.

Comment 7

[Robert Strong (they/them - no direct email)]

Agreed but it is the correct place for discussing adding tests that cover this bug. :)

Having said that I'm glad getting this bug tested is on your radar. Thanks!

Comment 8

[juan becerra [:juanb]]

3.5rc2(build2)
Mozilla/5.0 (Windows; U; Windows NT 6.0; mk; rv:1.9.1) Gecko/20090616 Firefox/3.5
Mozilla/5.0 (X11; U; Linux i686; mk; rv:1.9.1) Gecko/20090616 Firefox/3.5
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; mk; rv:1.9.1) Gecko/20090616 Firefox/3.5

Check for updates no longer shows the "yellow screen of death".

Comment 9

[Axel Hecht [:Pike]]

Over to damjan, this still needs to land on l10n-central.

Comment 10

[Damjan Georgievski]

Fixed in 3.5.1