Closed Bug 742099 Opened 11 years ago Closed 11 years ago

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


(Firefox :: PDF Viewer, defect)

Not set



Firefox 16
Tracking Status
firefox15 + fixed


(Reporter: mossop, Assigned: yury)




(1 file, 3 obsolete files)

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):

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 (, 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 ( 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 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)
Assignee: nobody → async.processingjs
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 is where all UI strings are stored. The 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)
Depends on: 748924
The properties file is addressed by chrome://pdfviewer/locale/ file can be found at the browser/locale/en-US/pdfviewer/ folder (mozilla-central) and @AB-CD@/browser/pdfviewer/ folders (l10n-central).

(See also
Attachment #622034 - Attachment is obsolete: true
Attachment #623261 - Flags: feedback?(l10n)
Comment on attachment 623261 [details] [diff] [review]
en-US pdf.js strings and 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.
Attachment #623261 - Flags: feedback?(l10n) → feedback+
Blocks: 757759
Attachment #623261 - Attachment is obsolete: true
Attachment #628791 - Flags: review?(l10n)
Comment on attachment 628791 [details] [diff] [review]
Additional pdf.js strings and fix

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

r=me with the comment fixes below.

::: browser/locales/en-US/pdfviewer/
@@ +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.
Attachment #628791 - Flags: review?(l10n) → review+
Re-arranged/re-grouped the strings and added comments in and files.

The fix had no changes
Attachment #628791 - Attachment is obsolete: true
Keywords: checkin-needed
Depends on: 748926
Blocks: 748923
No longer blocks: 714712
Target Milestone: --- → Firefox 16
Attachment #628910 - Flags: approval-mozilla-aurora+
Closed: 11 years ago
Resolution: --- → FIXED
Depends on: 762010
You need to log in before you can comment on or make changes to this bug.