Support localization of add-on's name and description via .properties files

[SebastianZ]

In #495 translation within the package.json file got implemented.
Though the initial request in issue #479 for making the name and description of an add-on localizable was to do that via the .properties files like it's already done for the preferences translations. That means to have two entries:

_<add-on name>__title=Add-on title
_<add-on name>__description=Localized description of the addon

where <add-on name> is the name of the add-on defined within the package.json file.

Sebastian

[freaktechnik]

This would mean that JPM would have to parse the .properties files, not something it ever did. Preferences are now generated and translated at runtime.

What is the rationale behind having the add-on name in the property name?

[SebastianZ]

What is the rationale behind having the add-on name in the property name?

The rationale is to have a unified way of adding translations. This would also allow localization tools like BabelZilla to handle them, as they don't support translating the package.json or RDFs, as far as I know.

Sebastian

[freaktechnik]

The rationale is to have a unified way of adding translations. This would also allow localization tools like BabelZilla to handle them, as they don't support translating the package.json or RDFs, as far as I know.

The question wasn't why you would want to have a property in the properties file. That (kind of) makes sense to me, since it avoids a compile step or copy & paste step when including the translations into your extension. It also has the benefit of BabelZilla supporting it without them modifying their config for their beta version to also accept JSON key-value files (transifex can do that, it's just disabled in adofex).

The question was however, why include the addon name in the property name and not call it something static that stays the same, whatever the extension's name happens to be. I seems rather unintuitive to me, that such a property would change the name based on the extension's name property.

[kumar303]

Can it not just be the following?

title=Add-on title
description=Localized description of the addon

[SebastianZ]

@freaktechnik wrote:

The rationale is to have a unified way of adding translations. This would also allow localization tools like BabelZilla to handle them, as they don't support translating the package.json or RDFs, as far as I know.

...

The question was however, why include the addon name in the property name and not call it something static that stays the same, whatever the extension's name happens to be. I seems rather unintuitive to me, that such a property would change the name based on the extension's name property.

I just picked up the original idea. I'd also be happy with static property names.

@kumar303 wrote:

Can it not just be the following?

title=Add-on title
description=Localized description of the addon

I'd assume that may conflict with existing add-ons. How about addon_title and addon_description?

Sebastian

[freaktechnik]

Oh, I've already updated the docs with it, but the homepage is also localizable, so there would also have to be a property for homepage.

[SebastianZ]

Oh, I've already updated the docs with it, but the homepage is also localizable, so there would also have to be a property for homepage.

Ah, cool! Missed that before. Thank you for updating the docs!

Sebastian

[asamuzaK]

addon_title or addon_description are a bit confusing.
How about
locale_title
locale_description

[SebastianZ]

addon_title or addon_description are a bit confusing.

It's the add-on's title and description and these properties will be placed in the .properties file of each locale. So, why's that confusing?

Sebastian

[asamuzaK]

I meant 'confusing' that it's not so clear of which field (term) those translations are for.
_title is used like term_title now.

For example, in package.json,

"preferences": [ { "type": "bool", "name": "MyPref", "title": "My pref title" } ]

And in .properties file,

MyPref_title = localized title

I'm not strongly opposed though.

[jc3213]

I could hardly remember that I had asked about support for localization of title and description via property files on bugzilla. I thought that should be done by Firefox not jpm.

If jpm can parse localization string of addon's title and description via property files too, I'd suggest that (function) should support homepage as well