742099 - Localize pdf.js strings and replace with the final strings for release

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, defect)

Description

[Dave Townsend [:mossop]]

We used temporary strings when landing pdf.js and they can't currently be localised. We should make sure to come up with finalized strings and a way to localize them before the move to aurora.

Comment 1

[Scoobidiver (away)]

Dupe of bug 738951?

Comment 3

[Scoobidiver (away)]

PDF Viewer is currently localized for a few locales by unofficial localizers (add-on developers that speak the language): https://github.com/mozilla/pdf.js/tree/master/l10n

Official localizers should localize pdf.js strings on Github.

Comment 4

[Axel Hecht [:Pike]]

I disagree.

Comment 5

[Scoobidiver (away)]

(In reply to Axel Hecht [:Pike] from comment #4)
> I disagree.
The current situation is add-on developers do the job for some locales with a potential low quality translation (consistency...) and let unlocalized some locales when there are no add-on developers that speak it.
What do you propose instead?

Comment 6

[Axel Hecht [:Pike]]

pdf.js is big enough of a feature to make it translation required across localizations. Thus, for the bundled add-on, the localization content should be picked up from the standard l10n system in hg, and exposed on the dashboard etc.

For the add-on-only module, you could pick the files up from our repos and bundle them up.

For the record, that's also the scheme that the feedback addon uses, and has been agreed as the way to go in the pdf.js kickoff meeting.

Comment 7

[Yury Delendik (:yury)]

(In reply to Scoobidiver from comment #3)
> Official localizers should localize pdf.js strings on Github.

Scoobidiver, could you specify point of contact(s) for the official localizers or CC on this bug?

There no issues with placing all localized files on hg. The current localizations are created in support of the pdf.js HTML viewer (http://mzl.la/pdf-js), and it can be decided to use those localization or not.

(In reply to Axel Hecht [:Pike] from comment #4)
> that's also the scheme that the feedback addon uses, and has been agreed as the way to go in the pdf.js kickoff meeting.

pdf.js has different architecture from normal add-on. Normally add-ons have XUL UI and strings are replaced by dtd/properties (http://mxr.mozilla.org/l10n-central/source/cs/browser/feedback/). The pdf.js add-on is created as HTML page -- all UI, communication and rendering is run as regular web page for security reasons.

Looks like that the most standard-convenient way for localizer would be create a XUL interface and don't deal with the HTML content (the exaclty same way Gaia is trying to do). However changing and rewriting add-on to be run with chrome privileges might trigger different type of concerns and risks.

Comment 8

[Axel Hecht [:Pike]]

The strings are in .properties files already, see https://github.com/mozilla/pdf.js/blob/master/l10n/de/viewer.properties and siblings. It's merely loading them via the chrome:// protocol, and putting the en-US reference file somewhere where the l10n proces picks them up. That location may very well depend on where the pdf.js addon ends up, wrt thunderbird possibly wanting to ship it, too. (Not sure about mobile)

Comment 9

[Yury Delendik (:yury)]

Attachment: Adds locale data to the pdf.js extension

per comment #8

Localizable files are/will be located in browser/app/profile/extensions/[e-mail]/l10n/

Comment 10

[Yury Delendik (:yury)]

This bug depends on new UI to be landed.

Axel, could you provide basic feedback about files locations? The viewer.properties is where all UI strings are stored. The metadata.inc is an XML fragment for the install.rdf -- it can be ignored (with new enabled built-in add-on interface this will not be visible)

Comment 11

[Yury Delendik (:yury)]

Attachment: en-US pdf.js strings and jar.mm fix

The properties file is addressed by chrome://pdfviewer/locale/viewer.properties. viewer.properties file can be found at the browser/locale/en-US/pdfviewer/ folder (mozilla-central) and @AB-CD@/browser/pdfviewer/ folders (l10n-central).

(See also https://github.com/mozilla/pdf.js/pull/1690)

Comment 12

[Axel Hecht [:Pike]]

Comment on attachment 623261 [details] [diff] [review]
en-US pdf.js strings and jar.mm fix

This looks good, key is that they're in browser/locales/en-US. Otherwise we'd need to fix l10n.ini, too. That'd still require a locales/en-US segment to be in the path, though.

Comment 13

[Yury Delendik (:yury)]

Attachment: Additional pdf.js strings and jar.mm fix

Comment 14

[Axel Hecht [:Pike]]

Comment on attachment 628791 [details] [diff] [review]
Additional pdf.js strings and jar.mm fix

Review of attachment 628791 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with the comment fixes below.

::: browser/locales/en-US/pdfviewer/viewer.properties
@@ +44,5 @@
>  thumb_page_canvas=Thumbnail of Page {{page}}
>  request_password=PDF is protected by a password:
>  open_file_label=Open
> +search.title=Search Document
> +search_label=Search

This should have a comment on whether it's a button or a section heading or so, i.e., noun vs verb.

search_button below looks like it's an action, a comment wouldn't hurt, though.

Comment 15

[Yury Delendik (:yury)]

Attachment: Additional pdf.js strings (with comments) and jar.mm fix

Re-arranged/re-grouped the strings and added comments in viewer.properties and chrome.properties files.

The jar.mm fix had no changes

Comment 16

[Anant Narayanan [:anant]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/875b78d17a4e

Comment 17

[:Gavin Sharp [email: [e-mail]]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6b583c1a218e

Comment 18

[Geoff Lankow (:darktrojan)]

https://hg.mozilla.org/mozilla-central/rev/875b78d17a4e