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.

Dupe of bug 738951?

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.

I disagree.

(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?

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.

(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.

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)

per comment #8 Localizable files are/will be located in browser/app/profile/extensions/uriloader@pdf.js/l10n/

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)

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 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 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.

Re-arranged/re-grouped the strings and added comments in viewer.properties and chrome.properties files. The jar.mm fix had no changes