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:
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
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.
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").
--> 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
Target Milestone: --- → Future
Read my post to the localizations newsgroup about a alternative to this and email me privately about what you think.
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
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
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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
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:email@example.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.
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.
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.
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.
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.
(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:firstname.lastname@example.org>).
(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...
> 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).
(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.
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
Not looking to implement this -> WONTFIX
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago → 9 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.