Closed Bug 257155 Opened 20 years ago Closed 17 years ago

Extension description is not localizable

Categories

(Toolkit :: Add-ons Manager, defect, P1)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9alpha6

People

(Reporter: jens.b, Assigned: mossop)

References

(
URL
)

Details

(Keywords: dev-doc-complete, Whiteboard: PRD:ADD-003h)

Attachments

(4 files, 2 obsolete files)

Checked in patch
15.39 KB, patch
mossop
: review+
Details | Diff | Splinter Review
Follow up leak fix
1.09 KB, patch
Gavin
: review+
Details | Diff | Splinter Review
testcase
5.28 KB, patch
mossop
: review+
Details | Diff | Splinter Review
the L10n.xpi attachment
2.68 KB, application/x-xpinstall
Details 
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.
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?
Flags: blocking-aviary1.0PR?
bsmedberg, wolf, can you weigh in on this one?
Assignee: bugs → bsmedberg
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.
(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)...
renominate if something can be hashed out.
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
*** Bug 255601 has been marked as a duplicate of this bug. ***
Couldn't we use contents.rdf in locale folder instead of contents.rdf in chrome
folder to do that ?
> 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.
(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 ?
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...
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?
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.
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.
(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.

(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?
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.
Keywords: helpwanted
(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.
(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)
So it means we should open a new bug for u.m.o to have it able to deal with
other files ?
(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.
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 :)
(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.
Depends on: 274068
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?
(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 
(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...
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.
(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
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).
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1? → blocking-aviary1.1-
(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.
(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.
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.
Priority: -- → P3
See this (http://kb.mozillazine.org/Localize_extension_descriptions) for what
seems to be the better workaround.
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.
I hope to take care of this bug in bug 285848
Depends on: 285848
QA Contact: bugs → extension.manager
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.
Assignee: benjamin → robert.bugzilla
Taking this.
Assignee: robert.bugzilla → dtownsend
Keywords: helpwanted
Priority: P3 → P1
Whiteboard: PRD:ADD-003h
(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.
Attached patch implementation rev 1 (obsolete) — — Splinter Review 
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.
Attachment #267158 - Flags: review?(robert.bugzilla)
Status: NEW → ASSIGNED
No longer depends on: 274068, 285848
Target Milestone: --- → Firefox 3 alpha6
Comment on attachment 267158 [details] [diff] [review]
implementation rev 1

Looks good and thanks Dave!
Attachment #267158 - Flags: review?(robert.bugzilla) → review+
Attached patch Checked in patch — — Splinter Review 
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.
Attachment #267158 - Attachment is obsolete: true
Attachment #269731 - Flags: review+
Just use the appropriate keyword dev-doc-needed as reminder. ;)
Keywords: dev-doc-needed
Tinderbox is showing a leak, I think this should sort it.
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.
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
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: dev-doc-needed
Resolution: --- → FIXED
Did you STILL not add in the ability to put newlines in the extension descriptions?  :-(
(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.
Flags: blocking-firefox3+
(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?).
And of course it qualified, if I'd finished reading my email.  Sorry for the extra bugspam...
Depends on: 386322
Attached patch testcase (obsolete) — — Splinter Review 
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.
Attachment #275996 - Flags: review?(robert.bugzilla)
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
Attachment #275996 - Flags: review?(robert.bugzilla) → review+
Attached patch testcase — — Splinter Review 
Updated comment.
Attachment #275996 - Attachment is obsolete: true
Attachment #276332 - Flags: review+
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
Flags: in-testsuite+
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. 

Adding to the bug for testing purposes.
this was verified awhile back.  marking verified now.
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: