Last Comment Bug 742099 - Localize pdf.js strings and replace with the final strings for release
: Localize pdf.js strings and replace with the final strings for release
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: PDF Viewer (show other bugs)
: Trunk
: All All
: -- normal (vote)
: Firefox 16
Assigned To: Yury Delendik (:yury)
:
: Brendan Dahl [:bdahl]
Mentors:
: 738951 (view as bug list)
Depends on: 748924 748926 762010
Blocks: 748923 757759
  Show dependency treegraph
 
Reported: 2012-04-03 16:42 PDT by Dave Townsend [:mossop]
Modified: 2013-12-27 14:26 PST (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed


Attachments
Adds locale data to the pdf.js extension (1.76 KB, patch)
2012-05-08 10:30 PDT, Yury Delendik (:yury)
no flags Details | Diff | Splinter Review
en-US pdf.js strings and jar.mm fix (2.66 KB, patch)
2012-05-11 12:55 PDT, Yury Delendik (:yury)
l10n: feedback+
Details | Diff | Splinter Review
Additional pdf.js strings and jar.mm fix (2.33 KB, patch)
2012-05-31 10:27 PDT, Yury Delendik (:yury)
l10n: review+
Details | Diff | Splinter Review
Additional pdf.js strings (with comments) and jar.mm fix (4.65 KB, patch)
2012-05-31 14:48 PDT, Yury Delendik (:yury)
akeybl: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Dave Townsend [:mossop] 2012-04-03 16:42:42 PDT
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) 2012-04-20 06:30:52 PDT
Dupe of bug 738951?
Comment 2 Scoobidiver (away) 2012-05-02 22:20:37 PDT
*** Bug 738951 has been marked as a duplicate of this bug. ***
Comment 3 Scoobidiver (away) 2012-05-07 22:43:59 PDT
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] 2012-05-07 23:04:25 PDT
I disagree.
Comment 5 Scoobidiver (away) 2012-05-07 23:31:34 PDT
(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] 2012-05-08 04:52:41 PDT
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) 2012-05-08 05:47:31 PDT
(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] 2012-05-08 05:52:27 PDT
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) 2012-05-08 10:30:20 PDT
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/
Comment 10 Yury Delendik (:yury) 2012-05-08 10:38:16 PDT
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) 2012-05-11 12:55:31 PDT
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)
Comment 12 Axel Hecht [:Pike] 2012-05-22 08:43:35 PDT
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) 2012-05-31 10:27:17 PDT
Created attachment 628791 [details] [diff] [review]
Additional pdf.js strings and jar.mm fix
Comment 14 Axel Hecht [:Pike] 2012-05-31 12:52:30 PDT
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) 2012-05-31 14:48:35 PDT
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
Comment 17 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-06-04 16:46:47 PDT
https://hg.mozilla.org/releases/mozilla-aurora/rev/6b583c1a218e
Comment 18 Geoff Lankow (:darktrojan) 2012-06-05 06:07:57 PDT
https://hg.mozilla.org/mozilla-central/rev/875b78d17a4e

Note You need to log in before you can comment on or make changes to this bug.