386370 - Provide more localization possibilities

Status: RESOLVED FIXED

(Calendar :: Provider: GData, defect)

Description

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Allow more localization - v1

Allow description and title localization for mozilla1.8 for gecko 1.9 see [1]. Also adds other preferences in the default prefs file.

http://developer.mozilla.org/en/docs/Localizing_extension_descriptions

Comment 1

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 270361 [details] [diff] [review]
Allow more localization - v1

This patch is not really ready yet. I'd like to have a way to automatically package all locales into the xpi. I at least have found a way to use the new gecko 1.9 install.rdf localization, by putting the following in the Makefile.in (where $(PP) is the preprocessor)

XPI_LOCALIZED=$(foreach locale,$(XPI_LOCALES),$(shell $(PP) $(topsrcdir)/calendar/locales/$(locale)/chrome/calendar/providers/gdata/install.rdf))
DEFINES += -DXPI_LOCALIZED='$(XPI_LOCALIZED)'

and including @XPI_LOCALIZED@ in the install.rdf

Until there is a nice build system way to do it, I'll probably do most of the stuff by hand. I'll update this patch to also include homepageURL a bit later

Comment 2

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Allow more localization - v3

This should do it, all ideas included.
* Bump version number
* Add AMO properties file
* Add extension name/description localization possibilities for both trunk and branch
* Build all locales that have gdata localizations automatically, if possible.
* Added all prefs to a default prefs file.

Comment 3

[Daniel Boelzle [:dbo]]

Comment on attachment 271718 [details] [diff] [review]
Allow more localization - v3

Please use the existing calendar/locales/shipped-locales file; r=dbo.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 271718 [details] [diff] [review]
Allow more localization - v3

After further testing this doesn't quite work as expected. Back to the drawing board...

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: patch v4

To get 0.2.2 out of the door, this patch is basically the previous patch without the build magic. I will use the rest of my patch here in a controlled environment to create the final package.

I am carrying forth the r+, since I didn't add anything new to the patch but just took out some pieces.

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED

Comment 7

[Axel Hecht [:Pike]]

amo.properties is a bit tough on the localization check tools. They currently don't support \ concatenation of lines.

Looking at the parsing code we use for real, http://lxr.mozilla.org/mozilla1.8/source/xpcom/ds/nsPersistentProperties.cpp#185, it'll be tricky to fix that, given that we just use regexps.

What is amo.properties used for?

Comment 8

[Stefan Sitter [:ssitter]]

(In reply to comment #7)

The ":" also breaks compare locales, resulting in log messages like:

Properties in ./chrome/calendar/providers/gdata/amo.properties don't match:
  In /builds/tinderbox/Sunbird-Mozilla1.8-l10n/Darwin_8.8.1_Clobber/
  mozilla/calendar/locales/en-US: (add these to your localization)
    Please read http
    Please use http

Comment 9

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Axel, I'm sorry for any inconvenience. If I give the file a different ending than .properties, does that help?

This file should give localizers the opportunity to localize the descriptions on addons.mozilla.org.

Comment 10

[Stefan Sitter [:ssitter]]

amo.properties doesn't seem to be used anywhere in the code. Or does addons.mozilla.org automatically creates the page information from amo.properties file?

As far as I know the translation of extension descriptions on addons.mozilla.org is / should be independent from the translation of Sunbird/Lightning.

Comment 11

[Axel Hecht [:Pike]]

One way to go about this is to just make compare locales ignore this file. Not sure how terrific that solution would be, but I would like to make the ignore rules be external to the actual compare-locales code anyway. I wouldn't want to fix the perl version, though.

Renaming the .properties file would work, too, though that may actually be a disservice to localizers that use tools.

Comment 12

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

AMO doesn't automatically create this information (although it would be a great idea ;), I would enter this by hand. I just thought it might give localizers more possibilites, since a localizer contacted me by email and asked me what the process is to localize the strings.

So possible solutions are:
* Remove amo.properties, since its not part of the application
* Rename amo.properties to exclude it from the compare locales scripts
* Reformat the file to make it readable by the scripts
* Make compare-locales ignore the file

I don't really mind which solution, I could live well with any.

Comment 13

[Simon Paquet [:sipaq]]

(In reply to comment #12)
> So possible solutions are:
> * Remove amo.properties, since its not part of the application
> * Rename amo.properties to exclude it from the compare locales scripts
> * Reformat the file to make it readable by the scripts
> * Make compare-locales ignore the file

I would vote for options 1-3. Of those three I prefer option 1.

Reasons:
1. compare-locales is a useful tool for mozilla-based applications, not 
   extensions. It should not be adapted to cater to edge cases from extensions.
2. There might come a time, when we ship Lightning/Sunbird with GDATA support 
   by default. Once this happens this file is obsolete.

Comment 14

[Simon Paquet [:sipaq]]

Philipp, can you please act on the amo.properties issue. We'll have a string freeze in about two weeks and many l10n tinderboxen are orange just because of this file.

I really don't want to burden localizers with this issue if I can prevent it.

Comment 15

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I sure can. I wasn't sure this was a final decision, but it shouldn't hurt to just remove it.

-> cvs rm'd amo.properties