Last Comment Bug 257155 - Extension description is not localizable
: Extension description is not localizable
Status: VERIFIED FIXED
PRD:ADD-003h
: dev-doc-complete
Product: Toolkit
Classification: Components
Component: Add-ons Manager (show other bugs)
: unspecified
: All All
: P1 major with 38 votes (vote)
: mozilla1.9alpha6
Assigned To: Dave Townsend [:mossop]
:
Mentors:
http://wiki.mozilla.org/User:Mossop:F...
: 255601 (view as bug list)
Depends on: 386322
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-27 10:24 PDT by Jens Bannmann
Modified: 2008-07-31 04:30 PDT (History)
53 users (show)
chofmann: blocking‑aviary1.0PR-
bugs: blocking‑aviary1.5-
mconnor: blocking1.9+
dtownsend: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
implementation rev 1 (15.37 KB, patch)
2007-06-04 09:50 PDT, Dave Townsend [:mossop]
robert.strong.bugs: review+
Details | Diff | Review
Checked in patch (15.39 KB, patch)
2007-06-25 14:04 PDT, Dave Townsend [:mossop]
dtownsend: review+
Details | Diff | Review
Follow up leak fix (1.09 KB, patch)
2007-06-25 14:40 PDT, Dave Townsend [:mossop]
gavin.sharp: review+
Details | Diff | Review
testcase (5.25 KB, patch)
2007-08-09 10:43 PDT, Dave Townsend [:mossop]
robert.strong.bugs: review+
Details | Diff | Review
testcase (5.28 KB, patch)
2007-08-11 20:53 PDT, Dave Townsend [:mossop]
dtownsend: review+
Details | Diff | Review
the L10n.xpi attachment (2.68 KB, application/x-xpinstall)
2007-11-09 15:36 PST, Tony Chung [:tchung]
no flags Details

Description Jens Bannmann 2004-08-27 10:24:14 PDT
When using localized builds of Firefox, all information for installed
third-party extensions stays in one language. It is not possible to specify, for
example, both english and german descriptions.

For Optimoz Mouse Gestures, which will ship with several locales in future
releases, this leads to a strange user experience: Firefox is localized, the
extension manager itself, too, and the whole extension including its preferences
panel is also localized. Only the texts displayed in the EM window (namely, the
extension name, description and author), are not!

I propose doing either:

 1) Allow specifying multiple values for each affected piece
    of information in install.rdf, like this:
      <em:name>Mouse Gestures</em:name>
      <em:name locale="en-US">Mouse Gestures</em:name>
      <em:name locale="de-DE">Mausgesten</em:name>
      <em:name locale="cs-CZ">Gesta myší</em:name>
    The em:name node without a locale attribute could serve
    as a fallback.

 2) Allow the extension's DTD to be named in install.rdf and
    apply it to the extension manager window, so authors can
    use XML Entities in install.rdf.

It was said somewhere that having official, localized releases of Firefox 1.0
was a priority for the Mozilla Foundation (and its international affiliates),
and I think that makes this problem an important issue.
Comment 1 Jens Bannmann 2004-08-27 10:30:53 PDT
As update.mozilla.org also needs localized descriptions at some point in the
future, alternative 1) is probably the better one.

Is this an issue that should be dealt with before the Preview Release, or should
it be postponed after the PR, or even after 1.0?
Comment 2 chris hofmann 2004-08-27 11:16:45 PDT
bsmedberg, wolf, can you weigh in on this one?
Comment 3 Benjamin Smedberg [:bsmedberg] 2004-08-27 11:40:32 PDT
The suggested XML is not valid XMLRDF...

But even if it were, our RDF backend does not understand lang-typed literals, so
we're up a creek. And the entity-thing won't work, because we have no URI to
refer to. Basically, this is not hackable in the 1.0 timeframe.
Comment 4 Jens Bannmann 2004-08-27 14:33:57 PDT
(In reply to comment #3)
> The suggested XML is not valid XMLRDF...
> 
> But even if it were, our RDF backend does not understand lang-typed literals, so
> we're up a creek. And the entity-thing won't work, because we have no URI to
> refer to. Basically, this is not hackable in the 1.0 timeframe.

I understand it would be best to have it in the back-end, but does it really
have to be there? Unless I miss something, the decision which text to show could
be implemented in the front-end, and RDFXML like the following could work:

<RDF:Description about="urn:mozilla:extension-info:mozgest:en-US"
	em:name="Mouse Gestures"
	em:description="..."
	em:author="..." />
<RDF:Description about="urn:mozilla:extension-info:mozgest:de-DE"
	em:name="Mausgesten"
	em:description="..."
	em:author="..." />

Of course, you could not use XUL templates then, but iterating from JS would be
possible - either by having a seq referencing the extension-info nodes, or by
just looking up the appropriate ones by URN (first the browser language, then a
fallback)...
Comment 5 chris hofmann 2004-08-30 12:49:59 PDT
renominate if something can be hashed out.
Comment 6 Benjamin Smedberg [:bsmedberg] 2004-08-31 15:27:28 PDT
*** Bug 255601 has been marked as a duplicate of this bug. ***
Comment 7 Ptit Lutin 2004-08-31 16:09:46 PDT
Couldn't we use contents.rdf in locale folder instead of contents.rdf in chrome
folder to do that ?
Comment 8 Benjamin Smedberg [:bsmedberg] 2004-08-31 17:09:01 PDT
> Couldn't we use contents.rdf in locale folder instead of contents.rdf in chrome
> folder to do that ?

We're talking about install.rdf, not any contents.rdf. The install.rdf
(especially when hosted over update.mozilla.org) may be independent of the
extension files themself.
Comment 9 Ptit Lutin 2004-08-31 17:54:35 PDT
(In reply to comment #8)
> > Couldn't we use contents.rdf in locale folder instead of contents.rdf in chrome
> > folder to do that ?
> 
> We're talking about install.rdf, not any contents.rdf. The install.rdf
> (especially when hosted over update.mozilla.org) may be independent of the
> extension files themself.

Sorry, you're right (i'm tired ;)). But is it really impossible to move this
optional property (description) to contents.rdf in the local folder ?
Comment 10 Julien Vinber 2004-09-01 04:33:59 PDT
Pourquoi les non anlgophone n'aurais pas le droit d'avoir des extention 100%
localizer...

On ne demande même pas de le faire, mais simplement 

> We're talking about install.rdf, not any contents.rdf.

Justement contents.rdf est une trés bonne solution. TOUT les élément localizable
devrais ce trouver dans contents.rdf, et plus rien dans install.rdf qui est lui
non localizable.

> The install.rdf bmay be independent of the extension files themself

Justement la description fait partie de l'extention, donc elle ne devrait pas ce
trouver dans install.rdf, mais bien dans local/fr-FR/extention/content.rdf

> especially when hosted over update.mozilla.org

Tres important aussi. Car si ce n'est pas prit en compte nous somme OBLIGER de
modifier install et donc impossible pour nous d'envisager les mise à jour...

you do not speak French.  Sorry, but I do not speak English (tanks google)...
You to see as that can pose problem not to take into account the person who does
not understand your language... mozilla should not be only planned for the
English user...
Comment 11 Pcdingo 2004-09-01 05:50:35 PDT
I am agree with other people, description translation is important and coud be
localize, it will be not very difficult to do, just take information on
locale/content.rdf. Why don't do it??
And also with new update extension system if user use for exemple a single
french version it will be never update, if extension could support multilanguage
(description inside) there was less single language version and as it extensions
in any language could be automatically update.

So please add this possibility, else if we can't localise all text why there is
localisation possibility?
Comment 12 Benjamin Smedberg [:bsmedberg] 2004-09-01 06:52:25 PDT
Please do not comment without a technical solution. Any solution must work for
both update.mozilla.org *and* the browser, which have very different packaging
schemes. contents.rdf is not a viable solution, period.
Comment 13 Xavier Robin 2004-09-08 23:15:01 PDT
Alternatively we could include locale.rdf files in the root of the xpi, for
example a fr-FR.rdf or de-DE.rdf (and why not en-US.rdf), being localized
install.rdf. When the browser begins the installation, he first looks if a "more
locale" file is available, and processes with it or the install.rdf.
Comment 14 Benjamin Smedberg [:bsmedberg] 2004-09-09 04:20:23 PDT
(In reply to comment #13)
> Alternatively we could include locale.rdf files in the root of the xpi, for

Any solution that involves files other than install.rdf *will not work*, because
update.m.o only deals with install.rdf.
Comment 15 Jens Bannmann 2004-09-09 14:09:15 PDT
(In reply to comment #12)
> Please do not comment without a technical solution. Any solution must work for
> both update.mozilla.org *and* the browser, which have very different packaging
> schemes. contents.rdf is not a viable solution, period.

Then what about the scheme proposed in comment 4? *Might* it be doable?
Comment 16 Benjamin Smedberg [:bsmedberg] 2004-09-09 16:53:25 PDT
Yes, it might be doable, but neither Ben or I is going to write the patch before
1.0.  The proposed RDF schema is also incomplete and difficult, you would have
to use localized predicates instead of em:name and em:description, not a whole
new extension resource.
Comment 17 O. Atsushi (Torisugari) 2004-09-16 19:13:21 PDT
(In reply to comment #16)
How about a new arc
<em:descURL>chrome://bananaextension/locale/bananaextension.properties</em:descURL>
a la em:iconURL?

The file bananaextension.properties is, for example,

#For EM
extension.name=Banana Extension
extension.description=This extension replaces your head with a banana.
#For Banana
bananaextension.optionstitle=Banana Settings
...
..
.

We can't use dtd's parameter-entities (e.g. &myextension.name.label;),
so that descURL should be either *.rdf or *.properties.

In this case, it's very easy to make this change backward compatible.
Comment 18 Jens Bannmann 2004-09-16 22:43:08 PDT
(In reply to comment #17)
> How about a new arc
>
<em:descURL>chrome://bananaextension/locale/bananaextension.properties</em:descURL>
> a la em:iconURL?
> 
> The file bananaextension.properties is (...)

As bsmedberg wrote: "Any solution that involves files other than install.rdf
*will not work*, because update.m.o only deals with install.rdf." (Comment 14)
Comment 19 Xavier Robin 2004-09-17 10:13:33 PDT
So it means we should open a new bug for u.m.o to have it able to deal with
other files ?
Comment 20 Wolf [:wolf] 2004-09-17 10:42:02 PDT
(In reply to comment #19)
> So it means we should open a new bug for u.m.o to have it able to deal with
> other files ?

No. It means you need to use the file it parses. :-) unless there's simply no
other way.
Comment 21 Paul Lacourse 2004-09-17 12:03:37 PDT
How about using the xml:lang attribute as described in the exemple #8
(http://www.w3.org/TR/rdf-syntax-grammar/example08.rdf) from the W3C spec
(http://www.w3.org/TR/rdf-syntax-grammar/)?
(Even after 1.0 release :)
Comment 22 O. Atsushi (Torisugari) 2004-09-18 06:13:18 PDT
(In reply to comment #21)
Mozilla's rdf parser doesn't seems that smart.
After parsed w3 example, serialized the datasource.

<?xml version="1.0"?>
<RDF:RDF xmlns:NS2="http://purl.org/dc/elements/1.1/"
         xmlns:NC="http://home.netscape.com/NC-rdf#"
         xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <RDF:Description RDF:about="http://example.org/buecher/baum"
                   lang="de"
                   NS2:description="Das Buch ist ausergewohnlich">
    <NS2:title>Der Baum</NS2:title>
    <NS2:title>The Tree</NS2:title>
  </RDF:Description>
  <RDF:Description RDF:about="rdf:#$Ju.Se3"
                   lang="en-US" />
  <RDF:Description RDF:about="rdf:#$Mu.Se3"
                   lang="en" />
  <RDF:Description RDF:about="rdf:#$Iu.Se3"
                   lang="en" />
  <RDF:Description RDF:about="http://www.w3.org/TR/rdf-syntax-grammar"
                   NS2:title="RDF/XML Syntax Specification (Revised)" />
</RDF:RDF>


The problem is, in parsed datasource, 
the resource "rdf:#$Ju.Se3" is totally independent from NS2:title.
I think it's hard to fix the RDF lossy-parsing bug by 1.0 release.
Comment 23 Jens Bannmann 2005-01-07 02:57:02 PST
I discovered that there already seems to be a way to override some install.rdf
properties via prefs - see
http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#4267
  extensions.%UUID%.name
  extensions.%UUID%.description
  extensions.%UUID%.creator
  extensions.%UUID%.homepageURL

However, this has obvious drawbacks:
- the info is not in the rdf itself, so it's unusable by UMO
- I guess it won't work as soon as the extension is disabled

Anyway, does anyone know how to include pref settings in a locale, or has got
the above working already?
Comment 24 NaWer 2005-01-15 01:36:36 PST
(In reply to comment #23)

> Anyway, does anyone know how to include pref settings in a locale, or has got
> the above working already?
Translation panel ( version 1.4.11 and other ?) at
http://nazodane.hp.infoseek.co.jp/extension/translation.xhtml 
Comment 25 Jens Bannmann 2005-01-15 01:42:19 PST
(In reply to comment #24)
> > Anyway, does anyone know how to include pref settings in a locale, or has got
> > the above working already?
> Translation panel ( version 1.4.11 and other ?) at
> http://nazodane.hp.infoseek.co.jp/extension/translation.xhtml 

No, that one actually overlays the extension manager window and replaces the
description when it is displayed - not a very stable solution...
Comment 26 Ted Mielczarek [:ted.mielczarek] 2005-01-17 09:47:16 PST
This will probably require bug 274068 to be fixed in order to work.  (Just
noticed that it's already a dependency.)  I'm putting some effort into
supporting this in UMO (at least on the RDF parsing side) in bug 271272.  UMO
will obviously need some database support for it before it will work.  Right now
Mozilla's RDF parser just ignores xml:lang, so the extension manager will just
use the first entry found for description etc.
Comment 27 Michael Lidman 2005-01-18 21:20:06 PST
(In reply to comment #23)
> Anyway, does anyone know how to include pref settings in a locale, or has got
> the above working already?

I got it working 
http://autocopy.mozdev.org/ 

The locale settings come from a .properties file. I put the locale settings in a
stringbundle. And set the pref from my Overlay.js file. When the extension is
disabled it keeps the language from the last time it was enabled.

I had truble with a few unicode charicters I had to substitute \u00e9 with
\u00c3\u00a9 not exactly sure why. But there is something not right with setting
unicode escaped charicters in a pref. Or at the very least there is something
wrong with they way I'm setting the pref that it chokes on some charicters
Comment 28 Thomas Bertels 2005-01-29 05:28:40 PST
I don't think that the name should be localizable because it would be difficult
for users of a localized version to find the extension site if they don't know
the real name of the extension.
But for the localization of the description, the solution of Jen seems good
(even if it would be easier for the translators and the extension programmer to
put it in the local contents.rdf).
Comment 29 Ville Pohjanheimo (inactive) 2005-05-30 07:57:58 PDT
(In reply to comment #28)
> I don't think that the name should be localizable because it would be difficult
> for users of a localized version to find the extension site if they don't know
> the real name of the extension.
The finding part is true, especially if the extension site (UMO) is not
localized. In most cases the name of course wouldn't be localized but for others
not-localizing-it doesn't make any sense. Consider User Agent Switcher, which
has a specific meaning when translated.
This is why the scheme should support localized names too. Let the localizers
decide.
Comment 30 Stefan Breunig 2005-05-30 09:22:21 PDT
(In reply to comment #29)

This doesn't make too much sense. Is Firefox translated? No, because it's a
name. Is Windows translated? No, though it's meaning is quite obvious. Most
extensions have meaningful titels, eg. Cookie Button, Linkification, Resizeable
Textarea. However this'll lead to a problem: Some are just not translateable
(eg. for German, there's no word for "Cookie" and Linkification can't be said in
one word and still keep it's real meaning). 
And: While talkign about ger ext in a ger forum and talking about fr ext in a fr
forum might be no problem, it will sure conflict on eg. mozillazine. If a french
says "I got a problem with ~french-ext-name~" only the french would really get
it. While french or german might be some "popular" or similar languages you can
maybe guess what's meant, but you can't for all. (Eg. Tabbrowser perfences - if
there isn't the word "extension" somewhere one might think that the poster had a
problem with the standard prefernces)
However, having a translated title if possible can be quite helpful, as you
recognize the extension by it's (original) name but you use the translated one
for renembering what it does. I'd say add a line for a translated name, but make
it much smaller than the real title (or use this line for an ultra-short
description). Eg. for the actual design add it after or below the title with the
same font as the description. Maybe you can add it before or after the creators,
but it shouldn't be as big as the title itself.
Comment 31 erikernst2 2005-05-30 09:33:30 PDT
I think it would be great when the description would be translated in
multi-language-extensions. But the Name should really be left.
Perhaps a few people don't like the multi-versions because of the engl.
description, even if the "core" of the extension with all menues is translated.
Comment 32 Thomas Bertels 2005-07-19 03:37:42 PDT
See this (http://kb.mozillazine.org/Localize_extension_descriptions) for what
seems to be the better workaround.
Comment 33 Stanislas Rolland 2005-08-24 23:15:47 PDT
Please do not decide for me if the name of my extension could be translated or
not. Please give me the possibility to translate it.
Comment 34 Robert Strong [:rstrong] (use needinfo to contact me) 2006-02-19 22:05:07 PST
I hope to take care of this bug in bug 285848
Comment 35 Jeremy Morton 2006-06-11 07:08:35 PDT
Might it be a good idea also to allow newlines and tabs in descriptions whilst fixing this bug, or would that be better as a new bug entry?  I noticed that these aren't allowed recently, and they'd be pretty useful in laying out the description better.
Comment 36 Dave Townsend [:mossop] 2007-05-29 04:42:05 PDT
Taking this.
Comment 37 Dão Gottwald [:dao] 2007-05-29 07:18:34 PDT
(In reply to comment #14)
> Any solution that involves files other than install.rdf *will not work*, because
> update.m.o only deals with install.rdf.

If that's still the case, it should probably be fixed on the AMO side.
One resource for all locales sounds like a design flaw.
Comment 38 Dave Townsend [:mossop] 2007-06-04 09:50:14 PDT
Created attachment 267158 [details] [diff] [review]
implementation rev 1

This patch implements localizable properties as per the spec in the url field. I will be adding some testcases for this as part of bug 382752.
Comment 39 Robert Strong [:rstrong] (use needinfo to contact me) 2007-06-25 13:10:59 PDT
Comment on attachment 267158 [details] [diff] [review]
implementation rev 1

Looks good and thanks Dave!
Comment 40 Dave Townsend [:mossop] 2007-06-25 14:04:52 PDT
Created attachment 269731 [details] [diff] [review]
Checked in patch

Last patch had some mild bitrot so here is the checked in version.

Checking in toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--  nsExtensionManager.js.in
new revision: 1.222; previous revision: 1.221
done

Going to hold this open to remind me to update devmo with some details on this.
Comment 41 Henrik Skupin (:whimboo) 2007-06-25 14:19:02 PDT
Just use the appropriate keyword dev-doc-needed as reminder. ;)
Comment 42 Dave Townsend [:mossop] 2007-06-25 14:40:25 PDT
Created attachment 269742 [details] [diff] [review]
Follow up leak fix

Tinderbox is showing a leak, I think this should sort it.
Comment 43 Dave Townsend [:mossop] 2007-06-25 15:05:24 PDT
Checking in nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--  nsExtensionManager.js.in
new revision: 1.223; previous revision: 1.222
done

Fix checked in but leak is apparently still there.
Comment 44 Dave Townsend [:mossop] 2007-06-26 04:12:56 PDT
Looks like the leak was caused by someone else and tinderbox was lying about the checkins to the build machine.

Added documentation to the following:

http://developer.mozilla.org/en/docs/Localizing_extension_descriptions
http://developer.mozilla.org/en/docs/Install_Manifests
http://developer.mozilla.org/en/docs/Firefox_3_for_developers
http://developer.mozilla.org/en/docs/Updating_extensions_for_Firefox_3
Comment 45 Jeremy Morton 2007-06-26 04:40:11 PDT
Did you STILL not add in the ability to put newlines in the extension descriptions?  :-(
Comment 46 Dave Townsend [:mossop] 2007-06-26 05:04:50 PDT
(In reply to comment #45)
> Did you STILL not add in the ability to put newlines in the extension
> descriptions?  :-(

That is a completely different issue. Please file a bug on it if there isn't already one.
Comment 47 Jeff Walden [:Waldo] (remove +bmo to email) 2007-06-26 10:36:22 PDT
(In reply to comment #41)

...which isn't to say you should use it as an excuse to not document something relatively simple to describe without non-obvious practical applicatins (I think this qualifies?).
Comment 48 Jeff Walden [:Waldo] (remove +bmo to email) 2007-06-26 10:38:00 PDT
And of course it qualified, if I'd finished reading my email.  Sorry for the extra bugspam...
Comment 49 Dave Townsend [:mossop] 2007-08-09 10:43:00 PDT
Created attachment 275996 [details] [diff] [review]
testcase

This is a testcase using the test harness from bug 382752, need this to check that in.

It simply installs a test extension, checks that the localized name is already available at that point, then restarts the em and checks that the name remains and then changles locale, disables the addon etc making sure hte correct name appears each time.
Comment 50 Robert Strong [:rstrong] (use needinfo to contact me) 2007-08-09 10:57:15 PDT
Comment on attachment 275996 [details] [diff] [review]
testcase

>Index: toolkit/mozapps/extensions/test/unit/test_bug257155.js
>===================================================================
>+  // Change to an unset locale
How about?
// Change to a locale not provided by the add-on
Comment 51 Dave Townsend [:mossop] 2007-08-11 20:53:33 PDT
Created attachment 276332 [details] [diff] [review]
testcase

Updated comment.
Comment 52 Dave Townsend [:mossop] 2007-08-11 21:13:55 PDT
Checked in.

RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/test_bug257155.js,v
done
Checking in toolkit/mozapps/extensions/test/unit/test_bug257155.js;
/cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/test_bug257155.js,v  <--  test_bug257155.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/addons/test_bug257155/install.rdf,v
done
Checking in toolkit/mozapps/extensions/test/unit/addons/test_bug257155/install.rdf;
/cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/addons/test_bug257155/install.rdf,v  <--  install.rdf
initial revision: 1.1
done
Comment 53 Tony Chung [:tchung] 2007-10-08 14:04:30 PDT
I have verified the following on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre: 

en-US:

name: L10N Test Extension (en-US)
desc: en-US description
---------

On Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9a9pre) Gecko/2007100605 Minefield/3.0a9pre:

de:

name: L10N Test Extension (de-DE)
desc: de-DE description

---------
on Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9a9pre) Gecko/2007100605 Minefield/3.0a9pre:

fr:

name: L10N Test Extension (fr-FR)
desc: fr-FR description
---------


However, i was unable to verify the other l10n builds yet, due to bug 398954.  Will finish the verification when the builds are working again. 
Comment 54 Tony Chung [:tchung] 2007-11-09 15:36:53 PST
Created attachment 288064 [details]
the L10n.xpi attachment

Adding to the bug for testing purposes.
Comment 55 Tony Chung [:tchung] 2008-03-25 14:22:55 PDT
this was verified awhile back.  marking verified now.

Note You need to log in before you can comment on or make changes to this bug.