255749 - Allow source l10n of help and DOMI (firefox)

Status: RESOLVED FIXED

(Firefox Graveyard :: Help Documentation, defect)

Description

[Jeff Walden (gone starting June 8)]

Firefox Help locale files are in two non-standard locations.  According to the
Firefox Localization document referenced,

"Firefox will be localized from the source tree through two centralized
locations. The core localized files shared between Thunderbird and Firefox are
located at mozilla/toolkit/locales in the CVS tree LXR. The localized files
which are used only by Firefox are located at mozilla/browser/locales LXR."

Was this an oversight or an intentional choice (perhaps offed to after 1.0)? 
I'm not going to be at all surprised if this is invalidated, but I am curious
about the reasons that would override simplifying localization efforts.

Comment 1

[Steffen Wilberg]

bsmedberg is the man to ask.

Comment 2

[Benjamin Smedberg]

I'm going to coopt this bug a little bit... I need to post my decisions to
npm.l10n soon also. This is the same problem with DOM inspector (and venkman,
when we get it work):

the en-US help files are going to stay where they are, and will be included in
all localized builds. Localized builds will have the option of including
localized help/DOMI as well. I'll post a patch shortly so that this works with
the build automation.

Comment 3

[chris hofmann]

adding to the radar

Comment 4

[Benjamin Smedberg]

Attachment: allow #define LOCALE_HAS_HELP 1 etc in browser/locales/ab-CD/defines.inc

in browser/locales/ab-CD/defines.inc you can now declare the following
variables:

#define LOCALE_HAS_HELP 1
  to distribute localized help xhtml and TOC
#define LOCALE_HAS_HELP_IMAGES 1
  to distribute localized help images
  (otherwise, you need to load them from a website as en-US does)
#define LOCALE_HAS_DOMI 1
  to distribute localized files for DOMI

Comment 5

[Benjamin Smedberg]

Comment on attachment 156450 [details] [diff] [review]
allow #define LOCALE_HAS_HELP 1 etc in browser/locales/ab-CD/defines.inc

This is no-risk for English builds, because they don't define the variables.

Comment 6

[Mike Shaver (:shaver emeritus)]

Comment on attachment 156450 [details] [diff] [review]
allow #define LOCALE_HAS_HELP 1 etc in browser/locales/ab-CD/defines.inc

a=shaver.

Comment 7

[Benjamin Smedberg]

Fixed on branch (not applicable on trunk yet)

Comment 8

[Axel Hecht]

Benjamin, shouldn't 

help.dtd  help.properties  helpMenuOverlay.dtd

rather move to toolkit/locales than to browser/locales?
Those are for localizing the help viewer.

Not sure about DOMI, I wonder whether we consider that to be a developer tool
for toolkit or a browser extension. I could see this going to toolkit, too. 
I recall there is a bug to get DOMI into Thunderbird, or am I mistaken?

Comment 9

[Benjamin Smedberg]

At this point in time, no. RJ and I need to figure out how to separate the help
system into backend and "help content" portions (in different chrome packages),
so that the xulrunner can include the backend, but that is a post-1.0 project.

The DOMI thing is also a post-1.0 project... we need to make it a real
extension, not the pseudo-extension of today. Putting those files in toolkit/
instead of browser/ means you have to put the #define in
toolkit/ab-CD/defines.inc, which I didn't want to do.

Comment 10

[u60234]

There are more images in the help files than what is represented in jar.mn. 

arrow-dn-sharp.png
arrow-up-sharp.png
cookie_accept.png
cookie_manager.png
download_manager.png
first.png
help-buttons.png
last.png
next.png
pg-landscape-small.png
pg-portrait-small.png
previous.png
print.png
searchbar.png
urlbar.png

Also, would it not be neater with a "images" subdirectory?

Comment 11

[u60234]

These files are also missing:

firebird-glossary.rdf
help-toc.rdf
welcome.xhtml

Comment 12

[Benjamin Smedberg]

Attachment: supplementary patch

I just landed this supplementary patch to fix the issues raised by Hasse.

Comment 13

[Michele Dal Corso]

Other two images are missing from jar.mn for help:

theme_manager.png
extension_manager.png

Comment 14

[Steffen Wilberg]

This bug is out of date. See bug 260705 instead, especially bsmedberg's fix:
https://bugzilla.mozilla.org/attachment.cgi?id=159729&action=diff