Bug 230596 (help.xpi)

Separate help-files from langenus.xpi into their own XPI to ease localisation

RESOLVED WONTFIX

Status

--
enhancement
RESOLVED WONTFIX
15 years ago
9 years ago

People

(Reporter: cnst+bmo, Unassigned)

Tracking

Trunk
Future

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.6b) Gecko/20031208

I am one of the localisers of Mozilla Application Suite. I found it to be
somewhat inconvenient that the help-files are put together with the other
language files, so that if one wants to translate the application, one is
advised to go through the help-files every time over again.

Given the nature of the help-files (they are not updated as often, and not
everyone is used to use them (I almost never used them)), it would be more
time-efficient to divide the help directory to a separate XPI, so that the
localisers will be free to localise the language package more often (i.e.
creating more versions of Mozilla to test for international users), as they
would not be required to maintain the help-directory in time.

This is done with regional settings right now. Isn't it time for the help-files
as well?

P.S. Given that the help files are divided into a different XPI, they can be
provided by a different localisation-team than the main language pack.

Reproducible: Always

Steps to Reproduce:
(Reporter)

Comment 1

15 years ago
Here is the discussion on netscape.public.mozilla.l10n:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=bt5q3v%24oce2%40ripley.netscape.com
Keywords: intl

Comment 2

15 years ago
I don't quite understand what you want. Are you asking for the help files to be
put in a different JAR file? The newsgroup posting doesn't seem to have any
relevance to this bug.
(Reporter)

Comment 3

15 years ago
I want it to be a separate XPI package. I.e. I suggest moving all files from the
help directory to a separate XPI package, just as regional settings are placed
in regus.xpi. So that localisers will need to translate three different
xpi-packages, langenus.xpi, regus.xpi, and this newly one called helpenus.xpi,
for example. Is it clear now? This way, localisers may manage to translate
help-files only for the major versions, while keeping up with langenus.xpi each
and every release (including alpha and beta ones). 

Logically, it also makes perfect sense, as user will be able to specify whether
he/she wants help-files at all during the initial installation process. 

P.S. The newsgroup posting should be just the same as the initial description of
this bug, except for the title (it is titled "Mozilla help-files: benefit of
creating a separate help XPI by default").

Comment 4

15 years ago
--> Future

Not really sure how to do this. Looks like an installer issue.

Daniel, do you know how to do something like this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
Target Milestone: --- → Future

Comment 5

15 years ago
Read my post to the localizations newsgroup about a alternative to this and
email me privately about what you think.
(Reporter)

Updated

15 years ago
Flags: blocking1.7a?

Comment 6

15 years ago
murenika: there is no way we're making 1.7a. We'll make 1.7b at best. I'm not
even 100% sure I want this feature on the trunk yet. I'm going to talk around first.

Unless someone comes and contributes a patch, it's not going to get in for 1.7a.
This bug isn't first priority on my list.
Target Milestone: Future → mozilla1.7beta

Comment 7

15 years ago
I've talked with other localizers and Help System developers and documentation
writers and they have all agreed to make this WONTFIX (which is what I've been
saying from the start).

This change would not be beneficial enough to make the change and having Help an
optional component is not of interest to us now. Not only that, it would be bad
for end-users to have to download a second language pack. It's not worth it.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WONTFIX

Updated

15 years ago
Flags: blocking1.7a?
(Reporter)

Comment 8

15 years ago
First of all, packs are downloaded via a javascript link, so there should be no
problem to include several packages at the same time and/or in the same link. 

I am reopening this bug in the hope that someone may find it interesting enough
to post some comments and/or create a patch. 
Alias: help.xpi
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 9

15 years ago
If you wish, but personally I would not like this kind of fix checked in. You
need to remember that I couldn't find anybody who supported this. Even reading
your newsgroup posting, everyone was unsure about it. The chances of finding
someone to fix this is unlikely, but you can if you want. This fix would only
cause unncessary complications, but I may reconsider if a patch comes along.

Reassigning to nobody to get this off my radar.
-->Future
Assignee: rlk → nobody
Status: REOPENED → NEW
Target Milestone: mozilla1.7beta → Future
(Reporter)

Comment 10

15 years ago
I am yet to receive any negative comments. So far, the response I got was
positive, with an example that some localisation teams already use (or have
used) this kind of idea (I am not confirming the above information, it is just a
quote). 

Here is the quote from message
<news://news.mozilla.org:119/btem1d$ngf2@ripley.netscape.com> written on
2004-01-06 by rado from mozilla.sk:
"But Your idea is not bad, e.g. Italians and Czechs have (or, had ?) the Help
files distributed independently, outside the language pack. And, the langpack
without Help is only half the size. "

P.S. Thank you for leaving the possibility for a patch. 

Comment 11

15 years ago
Constatine: I haven't found anyone who completely supported it. The person in
that message was a bit iffy about it. My last comment stands. This is my last
post to this bug unless a patch comes along.

Comment 12

15 years ago
I don't see the problem here. AFAIK, and the newsgroup message you quoted seems
to confirm this, there is nothing in the current system that stops you from
excluding Help from your language packs, if you wish to release them more
frequently. Just delete the "help" directory and the corresponding line in
install.js, and you are free to release as often as you like.

Comment 13

15 years ago
Hasse: I know, but read my comments above. I'm not a big fan of this system and
I'd prefer it not to be implemented. But as I said, I'll reconsider if a patch
comes along. If you support the system, make a patch and I'll look at it.
Otherwise, this bug will lay here until somebody does.

Comment 14

15 years ago
R.J., I apologize for not stating that my comment was a reply to Constantine's
proposal. I was merely pointing out to him that it is already possible with the
current system to do what he want, which is to release his language packs
without a help-directory.
(Reporter)

Comment 15

15 years ago
(In reply to comment #12)
> I don't see the problem here. AFAIK, and the newsgroup message you quoted seems
> to confirm this, there is nothing in the current system that stops you from
> excluding Help from your language packs, if you wish to release them more
> frequently. Just delete the "help" directory and the corresponding line in
> install.js, and you are free to release as often as you like.

I know that it is possible to do so. I tabled a proposal on the default
implementation of such a division, so that anyone could pick the package they
want to localise with no extra hassle of re-coding the installer script. See the
Subject of the newsgroup posting: "Mozilla help-files: benefit of creating a
separate help XPI _by default_"
(<news://news.mozilla.org:119/bt5q3v$oce2@ripley.netscape.com>). 
(Reporter)

Comment 16

15 years ago
(In reply to comment #13)
> I'll reconsider if a patch
> comes along. If you support the system, make a patch and I'll look at it.
> Otherwise, this bug will lay here until somebody does.

As I understand, such change must be approved by the drivers. Will drivers
approve this case? Otherwise, there is no reason to create a patch... 

Comment 17

15 years ago
> As I understand, such change must be approved by the drivers. Will drivers
> approve this case? Otherwise, there is no reason to create a patch... 

Where did you read that from? From what I know, all you need is module owner
approval (which is me) for this kind of change. You will need drivers approval
if you want it for 1.7 (assuming you miss the beta cycle).
(Reporter)

Comment 18

15 years ago
(In reply to comment #17)
> > As I understand, such change must be approved by the drivers. Will drivers
> > approve this case? Otherwise, there is no reason to create a patch... 
> 
> Where did you read that from? From what I know, all you need is module owner
> approval (which is me) for this kind of change. You will need drivers approval
> if you want it for 1.7 (assuming you miss the beta cycle).

The patch is about adding a new .xpi file to the *-xpi directories of the final
online installer. That is the reason I thought that it needs drivers approval.
Please, re-confirm that it does not. 
Product: Browser → Seamonkey

Comment 19

10 years ago
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED

Comment 20

9 years ago
Not looking to implement this -> WONTFIX
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago9 years ago
Keywords: helpwanted, intl
QA Contact: danielwang → help
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.