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

RESOLVED FIXED in Firefox 15

Status

()

Firefox
PDF Viewer
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: mossop, Assigned: yury)

Tracking

Trunk
Firefox 16
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15+ fixed)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
tracking-firefox14: --- → ?
tracking-firefox14: ? → +

Comment 1

5 years ago
Dupe of bug 738951?
tracking-firefox14: + → ---
tracking-firefox15: --- → +

Updated

5 years ago
Duplicate of this bug: 738951

Updated

5 years ago
Whiteboard: https://github.com/mozilla/pdf.js/pull/1636

Comment 3

5 years ago
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.

Comment 5

5 years ago
(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.
(Assignee)

Comment 7

5 years ago
(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)
(Assignee)

Updated

5 years ago
Assignee: nobody → async.processingjs
(Assignee)

Comment 9

5 years ago
Created attachment 622034 [details] [diff] [review]
Adds locale data to the pdf.js extension

per comment #8

Localizable files are/will be located in browser/app/profile/extensions/uriloader@pdf.js/l10n/
(Assignee)

Comment 10

5 years ago
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)
Depends on: 748924
(Assignee)

Comment 11

5 years ago
Created attachment 623261 [details] [diff] [review]
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)
Attachment #622034 - Attachment is obsolete: true
Attachment #623261 - Flags: feedback?(l10n)
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.
Attachment #623261 - Flags: feedback?(l10n) → feedback+
(Assignee)

Updated

5 years ago
Blocks: 757759
(Assignee)

Comment 13

5 years ago
Created attachment 628791 [details] [diff] [review]
Additional pdf.js strings and jar.mm fix
Attachment #623261 - Attachment is obsolete: true
Attachment #628791 - Flags: review?(l10n)
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.
Attachment #628791 - Flags: review?(l10n) → review+
(Assignee)

Comment 15

5 years ago
Created attachment 628910 [details] [diff] [review]
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
(Assignee)

Updated

5 years ago
Attachment #628791 - Attachment is obsolete: true
(Assignee)

Updated

5 years ago
Status: NEW → ASSIGNED
Keywords: checkin-needed
Whiteboard: https://github.com/mozilla/pdf.js/pull/1636
(Assignee)

Updated

5 years ago
Depends on: 748926
(Assignee)

Updated

5 years ago
Blocks: 748923
No longer blocks: 714712
https://hg.mozilla.org/integration/mozilla-inbound/rev/875b78d17a4e
Keywords: checkin-needed
Target Milestone: --- → Firefox 16

Updated

5 years ago
Attachment #628910 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/6b583c1a218e
status-firefox15: --- → fixed
https://hg.mozilla.org/mozilla-central/rev/875b78d17a4e
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Depends on: 762010
You need to log in before you can comment on or make changes to this bug.