325473 - Undo separation of language and region/content packs

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Robert Kaiser]

For getting source L10n to work in SeaMonkey (bug 286110), we need to remove the use of two locale codes per localization and get to using a single one instead.

Currently, the "content packs" (or region packs) use a second locale codes, but the basic idea behind them failed and them being separate to the main language pack causes more trouble than it helps (see some discussion in bug 180508).

Because of all that, we should get rid of the whole "content pack" logic on trunk. I'm currently starting to work on a patch to do that.

What I currently have/work on:
- changing jar.mn files to move files from US.jar to en-US.jar
- adjusting contents.rdf files of chrome://*-platform/ packages

What needs to be done:
- getting rid of internals (chrome registry wanting to set a region pack, etc.)
- adjusting/moving the pref panel

I'm really unsure about the "internals" stuff, as I'm not sure where we depend on region packs actually... I think this may also reach into profile defaults etc. Can someone give me pointer what to do there?

Comment 1

[Robert Kaiser]

This originally has been implemented in bug 62171 from what I see, so that may contain pointers to what needs to be undone. Bug 65241 and bug 65251 seem to have done the UI to that unused feature.
(Adding this comment so I find the pointer to the bugs again...)

Comment 2

[Robert Kaiser]

Attachment: part 1: move *-region into en-US.jar

Some times you don't believe how easy writing a patch for something like that is ;-)

This patch does the first part of this - it actually moves all *-region stuff from US.jar into en-US.jar, with just a few easy fixes!

The jar.mn fixes are only switching everything into the other .jar, the contents-region.rdf files get switched from US to en-US, all all redundant information that gets filled in by the global/ contents.rdf is stripped out of them. Note that editor-region contents.rdf is actually (wrongly) having the en-US stuff already and needs no change.

I've compiled SeaMonkey trunk with the patch successfully here, and a build with a new profile runs without any problems, also clicking the throbber and the relnote menu item work flawlessly (those get their URLs from *-region files).

Comment 3

[Robert Kaiser]

Comment on attachment 210422 [details] [diff] [review]
part 1: move *-region into en-US.jar

shifting review to bsmedberg, as I think it might be a good idea if he'd look into that. set Neil as sr instead ;-)

Comment 4

[Robert Kaiser]

Attachment: part 2: use language code for default profile stuff as well

This patch moves us over to use the language code (en-US) instead of "US" for the directories that carry default profile stuff as well.
The build still work correctly with a default profile after this patch, as we have all our stuff doubled in the defaults/ dir, I'm not sure though if we use the files in those directories at all.

Comment 5

[Benjamin Smedberg]

Comment on attachment 210422 [details] [diff] [review]
part 1: move *-region into en-US.jar

I don't have the time to review this.

Comment 6

[Robert Kaiser]

Comment on attachment 210422 [details] [diff] [review]
part 1: move *-region into en-US.jar

handing over those reviews to jag - I hope you got more time and understand that stuff well enough (it's xpfe, so I guess you should ;-)

Comment 7

[Robert Kaiser]

I have done a vanilla trunk build, created a new profile with it, rebuilt with part 1+2 patches, and launched that profile again.
The good news: build and launching it work without problems
The bad news: it's a mess behind the scenes - both US.jar and the new stuff inside en-US.jar are there, the new entries just get added to installed-chrome.txt and the chrome registry (chrome.rdf) has both locations of *-region registered. above all, the user profile's chrome.rdf references a mixture of them as "selected".
I'm not sure how we could solve that, as we can't remove stuff from installed-chrome.txt ot the chrome registry in the build process... anyways, after clobbering dist/bin/chrome, everything's fine - and even without it, the build work just fine as long as the new and old locations are just copies of each other (i.e. we don't change the actualy region content).

Comment 8

[Robert Kaiser]

Attachment: part 3: remove region selection from profile manager UI

I figure it's best to do small patches for every single step, as those are easier to review :)

This is part 3, which removes region selection from profile manager UI, and renaming the item to what it really is - "Select Language..."

Along with that, I removed the unused moreBtn.label from selectLang.dtd and made the list recognize langVersion, so that only current language packs can be selected (I saw a whole lot of empty lines in that list when testing for the earlier patches, that's the profile-manager-side incarnation of bug 302245, which should be fixed with this - the relevant code parts are "stolen" from that bug report).
We still care to close out region packs from the language list, in case someone still has an older chrome registry lying around that has region packs registered.

It's too late today for testing the patch, so this is still untested. I'll only request reviews once I have tested the patch here locally.

Comment 9

[Robert Kaiser]

Comment on attachment 211223 [details] [diff] [review]
part 3: remove region selection from profile manager UI

OK, this compiles well, and it's even refreshing to see how simple and clearly understandable that dialog in the profile manager is with the patch :)

Comment 10

[Robert Kaiser]

As a note to myself and anyone who might be interested, the following searches should turn up future obsolete places where content/region packs are handled in our code:
http://lxr.mozilla.org/mozilla/search?string=localeType
http://lxr.mozilla.org/mozilla/search?string=contentlocale

The first one looks fairly easy to solve, the second one makes me wonder though: even browser and toolkit reference it, but they haven't been using content pack for quite some time now...

Comment 11

[Robert Kaiser]

Another such note with lxr search URLs:
http://lxr.mozilla.org/mozilla/search?string=contentpack
http://lxr.mozilla.org/mozilla/search?string=content-pack

Actually, I should try to catch most/all of those with patch 4 - at least that's one of the targets here...

Comment 12

[Robert Kaiser]

OK, I have a patch now that moves the UI langauge selection into communicator UI and should resolve almost all remaining issues (this will be the biggest of those patches). I'll attach it shortly (as soon as it's tested).

That patch (part 4) will also fix the rough ends of the previous ones:
- parts 1 and 2 may break installers by not fixing the langenus.jst files and package lists.
- along with part 3, the relevant help section should be corrected.


Some issues will still stay open, though, which are more in core stuff:

The chrome registry refers to content packs, see relevant results of those searches:
http://lxr.mozilla.org/mozilla/search?string=content+pack
http://lxr.mozilla.org/mozilla/search?string=localeType

We have a startup switch for setting a content pack, see the relevant results of http://lxr.mozilla.org/mozilla/search?string=contentlocale

Note that help knows the concept of "help content packs", which are something different than what we are handling here, but turn up in some searches.

Comment 13

[jag (Peter Annema)]

Comment on attachment 211223 [details] [diff] [review]
part 3: remove region selection from profile manager UI

Index: mozilla/profile/resources/content/selectLang.xul
===================================================================

+<!ENTITY % brandDTD SYSTEM "chrome://branding/locale/brand.dtd" >

Remove that space at the end on both those lines.

r=jag with those nits addressed.

Comment 14

[Robert Kaiser]

Attachment: part 4: move pref panel into communictor pefs in suite/ and fix rough edges of parts 1-3

OK, there comes the really hard (and scary *g*) part.
This patch does the following:
- stop building extensions/content-packs (content-packs.jar)
- move the pref panel into communicator/pref instead, where all other common panels reside - and strip content pack switching from the panel
- add this in the correct places in suite/ along with new jar.mn and Makefiles to build it from there
- add the panel in pref windows as a usual panel, no overlayed extension
- correct help for that changed situation
- fix embed and netwerk to point to to en-US instead of US
- correct package lists and installer scripts to deal with that changed situation

All added/removed files are in the patch, except the cvs removal of extensions/content-packs which should be done when the patch is applied.

Maybe we should do a cvs copy to keep the history of the .xul/.dtd for the pref panel.

Comment 15

[Robert Kaiser]

Comment on attachment 211496 [details] [diff] [review]
part 4: move pref panel into communictor pefs in suite/ and fix rough edges of parts 1-3

bsmedberg, even if you don't want to review all the changes here, could you please review the build changes at the beginning of this patch (allmakefiles.sh, configure.in, build/unix/modules.mk)?
I think those should be fairly trivial, but I'd like to be sure everything's right with that

Comment 16

[Robert Kaiser]

Attachment: part 4a: correct installer manifests

Here's a small additional patch for fixing the config.it files of our installers.
This should actually have been part of the installer changes in part 4, but I just realized those need fixing as well...

Comment 17

[Andrew Schultz]

Comment on attachment 211499 [details] [diff] [review]
part 4a: correct installer manifests

>Index: mozilla/xpinstall/packager/unix/config.it
>-[Component7]
...
> [Component8]

please renumber the rest of the components

Comment 18

[Robert Kaiser]

Attachment: part 4 - pref panel xul/dtd files: diff of old pref-contentpacks vs. new pref-locales files

As requested by jag, here's a diff of the pref panel's xul/dtd files against the old versions, showing the real changes I made - basically stripping all content packs stuff and adopting text in the UI accordingly.
Note that I did a diff -w of the .dtd, as I adjusted the file to have all localizeable strings starting in the same column.

As I mentioned before, we should probably do a cvs copy of those two files to keep their history.

Comment 19

[Ian Neal]

(In reply to comment #14)
> Created an attachment (id=211496) [edit]
> part 4: move pref panel into communictor pefs in suite/ and fix rough edges of
> parts 1-3
> 
I would argue that suite/common/prefs or suite/common/prefs/content is better than suite/common/content/pref as the first two keep all the prefs code together whereas the last one keeps all the common xul/js code together - i.e. the last one structures it as it is built.
I would also argue that the "chrome" in the locales is unneeded increase in depth of the directory structure.

Comment 20

[Robert Kaiser]

(In reply to comment #19)
> I would argue that suite/common/prefs or suite/common/prefs/content is better
> than suite/common/content/pref as the first two keep all the prefs code
> together whereas the last one keeps all the common xul/js code together - i.e.
> the last one structures it as it is built.

suite/common/pref/ would work for me - Neil, what's your opinion on that?

> I would also argue that the "chrome" in the locales is unneeded increase in
> depth of the directory structure.

That one is to fit exactly to what all other apps use, I don't want to change this.

Comment 21

[Ian Neal]

(In reply to comment #20)
> (In reply to comment #19)
> > I would argue that suite/common/prefs or suite/common/prefs/content is better
> > than suite/common/content/pref as the first two keep all the prefs code
> > together whereas the last one keeps all the common xul/js code together - i.e.
> > the last one structures it as it is built.
> 
> suite/common/pref/ would work for me - Neil, what's your opinion on that?
I think most after apps use prefs rather than pref is a directory name.
> 
> > I would also argue that the "chrome" in the locales is unneeded increase in
> > depth of the directory structure.
> 
> That one is to fit exactly to what all other apps use, I don't want to change
> this.
Just to contridict myself, just because other apps do it, doesn't mean it is the best way.

Comment 22

[Pavel Franc - Mozilla.cz]

> Just to contridict myself, just because other apps do it, doesn't mean it is
> the best way.

The purpose of chrome directory is to separate files that go into ab-cd.jar i.e. .dtd and .properties files. To have a single directory for chrome files without oher profile/installer stuff is important for some l10n tools.

Comment 23

[Robert Kaiser]

(In reply to comment #22)
> The purpose of chrome directory is to separate files that go into ab-cd.jar
> i.e. .dtd and .properties files. To have a single directory for chrome files
> without oher profile/installer stuff is important for some l10n tools.

Yes, the main reason for chrome/ is that everything outside that dir (search plugins, other localizable profile defaults, installer stuff, etc.) is know to not be well-handled by localization tools, but most stuff in chrome/ can be handled by such tools (mainly .dtd/.properties files, though we have exceptions). And localizers depend on their tools a lot (including myself, so I know of their importance).

Comment 24

[jag (Peter Annema)]

Comment on attachment 211596 [details] [diff] [review]
part 4 - pref panel xul/dtd files: diff of old pref-contentpacks vs. new pref-locales files

File: mozilla/extensions/content-packs/resources/content/pref-contentpacks.xul
==============================================================================

>+<!ENTITY % prefLocalesDTD SYSTEM "chrome://communicator/locale/pref/pref-locales.dtd" >

Remove the space at the end here.

>+      onload="parent.initPanel('chrome://communicator/content/pref/pref-locales.xul'); "

And here.

>+      // XXX This should have really been done in the chrome registry itself,
>+      // not be in front-end code, but this patch was only to get this mostly
>+      // working for Mozilla 1.1b
>+      // "The code below must die before [Mozilla] 1.1final!!" ;-)

Do we still think this? Has a bug been filed? If there is a bug, let's mention it.

File: mozilla/extensions/content-packs/resources/locale/en-US/pref-contentpacks.dtd
===================================================================================

>-<!ENTITY uninstallContentPack.accesskey "u">
>-<!ENTITY uninstallContentPack.label     "Uninstall">
> <!ENTITY uninstallLanguagePack.accesskey "n">
> <!ENTITY uninstallLanguagePack.label     "Uninstall">

Let's change the remaining accesskey to "U".

r=jag

Comment 25

[jag (Peter Annema)]

Comment on attachment 211596 [details] [diff] [review]
part 4 - pref panel xul/dtd files: diff of old pref-contentpacks vs. new pref-locales files

Few more nits:

+<!ENTITY languageIntro.label             "From the list below, you can select the language for text that appears in dialog boxes, menus, toolbars and button labels.">

No need for that first comma.

+<!ENTITY restartOnLangChange.label       "Changes of the selcted language take effect when you restart &brandShortName;.">

"Language preferences will take effect when you restart &brandShortName;"

Comment 26

[jag (Peter Annema)]

Comment on attachment 211496 [details] [diff] [review]
part 4: move pref panel into communictor pefs in suite/ and fix rough edges of parts 1-3

>Index: mozilla/extensions/help/resources/locale/en-US/cs_nav_prefs_appearance.xhtml
>===================================================================
>+<p>The language selection preferences panel allows you to change the language
>+  to use for displaying the user interface of &brandShortName;.</p>

How about:

The language selection preferences panel allows you to change the language used in the user interface of &brandShortName;.

>Index: mozilla/extensions/help/resources/locale/en-US/nav_help.xhtml
>===================================================================

>-<p>The content pack you use affects the home page, bookmarks, toolbar contents,
>-  Sidebar, and other items.</p>

Let's have something along these lines surface somewhere.

>Index: mozilla/extensions/help/resources/locale/en-US/help-toc.rdf
>===================================================================
>+        <rdf:li><rdf:Description ID="appearance_pref_locales" nc:name="Languages" nc:link="cs_nav_prefs_appearance.xhtml#locales"/> </rdf:li>

This should be nc:name="Locales" to be consistent.

>Index: mozilla/suite/common/jar.mn
>===================================================================
>+##ifdef MOZ_XUL_APP
>+#% content communicator %content/communicator/ xpcnativewrappers=yes
>+##else
>+#*     content/communicator/contents.rdf                        (content/contents.rdf)
>+##endif
>+      content/communicator/pref/pref-locales.xul               (content/pref/pref-locales.xul)

Have these line up (I believe you already changed it locally).

>Index: mozilla/xpfe/components/prefwindow/resources/locale/en-US/preftree.dtd
>===================================================================

>+<!ENTITY locales.label "Languages">

> <!ENTITY languages.label "Languages">

I wonder if it'll be confusing to have two panels called "Languages". One deals with the language used in the UI, the other with the preferred language for content.

I've reviewed everything but the *.jst changes. They look ok, but I'd like to take a harder look at them.

Comment 27

[Robert Kaiser]

(In reply to comment #24)

> >+      // XXX This should have really been done in the chrome registry itself,
> >+      // not be in front-end code, but this patch was only to get this mostly
> >+      // working for Mozilla 1.1b
> >+      // "The code below must die before [Mozilla] 1.1final!!" ;-)
> 
> Do we still think this? Has a bug been filed? If there is a bug, let's mention
> it.

Actually, the situation regarding this has unfortunately not changed since when the workaround has been done. That stuff has been introduced by bug 142623 which is still open because a real fix was never created (blame says some "jaggernaut" has checked in the workaround, but it actually has been done by jrgmorrsion)...

(In reply to comment #26)
> (From update of attachment 211496 [details] [diff] [review] [edit])
> >Index: mozilla/extensions/help/resources/locale/en-US/cs_nav_prefs_appearance.xhtml
> >===================================================================
> >+<p>The language selection preferences panel allows you to change the language
> >+  to use for displaying the user interface of &brandShortName;.</p>
> 
> How about:
> 
> The language selection preferences panel allows you to change the language used
> in the user interface of &brandShortName;.

Sounds good to me.

> >Index: mozilla/extensions/help/resources/locale/en-US/nav_help.xhtml
> >===================================================================
> 
> >-<p>The content pack you use affects the home page, bookmarks, toolbar contents,
> >-  Sidebar, and other items.</p>
> 
> Let's have something along these lines surface somewhere.

Yes, we should do that. I'll come up a solution once I'm awake again (it's been an exhausting weekend)...

> >Index: mozilla/extensions/help/resources/locale/en-US/help-toc.rdf
> >===================================================================
> >+        <rdf:li><rdf:Description ID="appearance_pref_locales" nc:name="Languages" nc:link="cs_nav_prefs_appearance.xhtml#locales"/> </rdf:li>
> 
> This should be nc:name="Locales" to be consistent.

Hmm, when I changed that, I thought it might be displayed to the user. If it isn't, I should use "Locales", that's correct.

> >Index: mozilla/xpfe/components/prefwindow/resources/locale/en-US/preftree.dtd
> >===================================================================
> 
> >+<!ENTITY locales.label "Languages">
> 
> > <!ENTITY languages.label "Languages">
> 
> I wonder if it'll be confusing to have two panels called "Languages". One deals
> with the language used in the UI, the other with the preferred language for
> content.

Yes, I've been thinking about that, but I haven't found a good solution for that problem yet :-/

Any ideas?

> I've reviewed everything but the *.jst changes. They look ok, but I'd like to
> take a harder look at them.

OK, I won't check in before you have done that ;-)
(Still need to wait for sr anyways...)

Comment 28

[jag (Peter Annema)]

(In reply to comment #27)

> Actually, the situation regarding this has unfortunately not changed since
> when the workaround has been done. That stuff has been introduced by bug
> 142623 which is still open because a real fix was never created (blame says
> some "jaggernaut" has checked in the workaround, but it actually has been
> done by jrgmorrsion)...

Well, I guess at least there's a bug. Let's mention it in this comment :-)


> > This should be nc:name="Locales" to be consistent.
> 
> Hmm, when I changed that, I thought it might be displayed to the user. If it
> isn't, I should use "Locales", that's correct.

I just checked, it is displayed to the user, so "Languages" it is.


> > I wonder if it'll be confusing to have two panels called "Languages". One
> > deals with the language used in the UI, the other with the preferred
> > language for content.
> 
> Yes, I've been thinking about that, but I haven't found a good solution for
> that problem yet :-/
> 
> Any ideas?

None yet.

Comment 29

[Robert Kaiser]

Attachment: part 4, v2: move pref panel, fix rough edges of parts 1-3; with review nits fixed

This second version of part 4 has jag's review nits fixed, no other changes to the previous version(s) - other than also including the installer manifests in the one patch.

To summarize, the build config changes of this already have r=bsmedberg, the installer manifests have r=ajschult, most of the rest already has r=jag, excluding the *.jst files that still need to be reviewed by him.

Comment 30

[Robert Kaiser]

After some IRC discussion, we have settled on using suite/common/pref/ as the directoy for the pref window stuff, including the locale panel introduced in this bug. This directory basically maps to chrome://communicator/content/pref/ from the chrome's view.
I won't attach a new patch for that, but I'll do the changes locally and care that everything builds alright (trivial changes actually).

Comment 31

[jag (Peter Annema)]

Comment on attachment 213667 [details] [diff] [review]
part 4, v2: move pref panel, fix rough edges of parts 1-3; with review nits fixed

Let me see if I understand this correctly.

unix/regus.jst doesn't explicitly name bin/defaults and bin/searchplugins 'coz it just installs all of bin/* in one go, including all subdirectories, which includes chrome, defaults and searchplugins.

mac/regus.jst seems to do the same thing, but with s/bin/viewer/.

OS/2 just does what Windows does, and Windows explicitly calls out bin/chrome, bin/defaults and bin/searchplugins so on Mac the search plugins can be installed into a differently named folder (this is from when they were dreaming of having one .jst file for all platforms), but if you restrict this code to just Windows it effectively does the same as if you'd just had addDirectory("", "bin', fProgram, "");

And as we just saw, Mac doesn't really wish to install the search plugins into a separate directory any longer, so the Windows and OS/2 regus.jst could just do s/bin\/chrome/bin/ on the first addDirectory() and remove the special cased addDirectory()s for bin/defaults and bin/searchplugins, which for you means you don't need to copy that code into their respective langenus.jst files. Maybe someday we'll actually be able to merge these .jst files? :-)

Btw, if you decide to leave that code in for some reason:

  fTarget = getFolder("Program", searchPlugins);

will have |undefined| as the value for searchPlugins.

r-, but only 'coz I wanna see a final patch.

Comment 32

[Robert Kaiser]

(In reply to comment #31)
> unix/regus.jst doesn't explicitly name bin/defaults and bin/searchplugins 'coz
> it just installs all of bin/* in one go, including all subdirectories, which
> includes chrome, defaults and searchplugins.

True, looks like that, and I guess that should work fine for all platforms.

> mac/regus.jst seems to do the same thing, but with s/bin/viewer/.

Yes, and from what I see, that's a bug - mac/*.jst are unused anyways though, IIRC.

> OS/2 just does what Windows does, and Windows explicitly calls out bin/chrome,

Hmm... I realize that my patch would have made them install bin/* and install defaults and searchplugins a second time afterwards, which is probably not what we want...

> And as we just saw, Mac doesn't really wish to install the search plugins into
> a separate directory any longer, so the Windows and OS/2 regus.jst could just
> do s/bin\/chrome/bin/ on the first addDirectory() and remove the special cased
> addDirectory()s for bin/defaults and bin/searchplugins, which for you means you
> don't need to copy that code into their respective langenus.jst files. Maybe
> someday we'll actually be able to merge these .jst files? :-)

They're actually more or less the same in the new patch I'll attach in a second, their biggest difference being whitespace and windows installing the mapi stuff as well, I've removed the other small differences and sync'ed the files.

Comment 33

[Robert Kaiser]

Attachment: part 4, v3: move pref panel, fix rough edges of parts 1-3; also fix *.jst nits

This patch fixes all of jag's nits, also those for the *.jst files and is using a single addDirectory() on all platforms now. I also included the removal of the regus.jst files again, which I missed in the v2 patch. I'm also using the correct path for pref-locales.xul now.
(BTW, the unix langenus.jst contains a reordering of pipnss/pippki chrome registration, which doesn't matter but reduces the cross-platform-diff size of those .jst files.)

What's not included in any patch is the step of cvs removing mozilla/extensions/content-packs after this all has been checked in, I hope I can count your reviews as implicitely signing off that one as well.

Comment 34

[jag (Peter Annema)]

Comment on attachment 214310 [details] [diff] [review]
part 4, v3: move pref panel, fix rough edges of parts 1-3; also fix *.jst nits

Index: mozilla/xpinstall/packager/mac/langenus.jst
===================================================================
RCS file: /cvsroot/mozilla/xpinstall/packager/mac/langenus.jst,v
retrieving revision 1.22
diff -u -7 -p -r1.22 langenus.jst
--- mozilla/xpinstall/packager/mac/langenus.jst	19 Mar 2005 00:00:29 -0000	1.22
+++ mozilla/xpinstall/packager/mac/langenus.jst	7 Mar 2006 14:45:00 -0000
@@ -25,17 +25,17 @@ logComment("initInstall: " + err);
 fProgram = getFolder("Program");
 logComment("fProgram: " + fProgram);
 
 if (verifyDiskSpace(fProgram, srDest))
 {
     var chromeType = LOCALE;
     err = addDirectory("",
-                       "viewer",
-                       fProgram,
-                       "");
+                       "bin",     // dir name in jar to extract 
+                       fProgram,  // Where to put this file (Returned from GetFolder) 
+                       "");       // Force Flag 
     logComment("addDirectory() returned: " + err);

I'm not 100% sure, but I think you'll wanna keep this as viewer, not bin.

KaiRo just pointed out these .jst files are unused on the Mac, and we should just remove them.

Agree there, but for now let's keep this as viewer. (Hey, it'll reduce the size of your patch! ;-) )

r+

Comment 35

[[e-mail]]

Comment on attachment 214310 [details] [diff] [review]
part 4, v3: move pref panel, fix rough edges of parts 1-3; also fix *.jst nits

Is a diff between pref-locales.xul and pref-contentpacks.xul available?

Comment 36

[[e-mail]]

Comment on attachment 210548 [details] [diff] [review]
part 2: use language code for default profile stuff as well

Patches 2 & 3 shouldn't really have been separate.

Comment 37

[[e-mail]]

Comment on attachment 211223 [details] [diff] [review]
part 3: remove region selection from profile manager UI

>-<!DOCTYPE dialog SYSTEM "chrome://communicator/locale/profile/selectLang.dtd">
>+<!DOCTYPE dialog [
>+<!ENTITY % brandDTD SYSTEM "chrome://branding/locale/brand.dtd" >
>+%brandDTD;
>+<!ENTITY % selectLangDTD SYSTEM "chrome://communicator/locale/profile/selectLang.dtd" >
>+%selectLangDTD;
>+]>
You're not adding branding. sr=me with this hunk removed.

Comment 38

[Robert Kaiser]

(In reply to comment #37)
> (From update of attachment 211223 [details] [diff] [review] [edit])
> You're not adding branding.

I am, in a way. The entity lang.version I'm using is found in brand.dtd

Comment 39

[[e-mail]]

(In reply to comment #38)
>(In reply to comment #37)
>>(From update of attachment 211223 [details] [diff] [review])
>>You're not adding branding.
>I am, in a way. The entity lang.version I'm using is found in brand.dtd
D'oh!

Comment 40

[[e-mail]]

Comment on attachment 214310 [details] [diff] [review]
part 4, v3: move pref panel, fix rough edges of parts 1-3; also fix *.jst nits

>+      var newLanguagePack = parent.hPrefWindow.wsm.dataManager.getItemData( "chrome://content-packs/content/pref-contentpacks.xul", "languagePackList" ).prefvalue;
Old URL! sr=me with this fixed.

Comment 41

[Robert Kaiser]

All parts are checked in now.

I'll wait a bit for the cvs remocal of extensions/content-packs and then mark the bug as fixed.

Comment 42

[Robert Kaiser]

OK, content-packs/ has been cvs removed, this means that the content pack story is now history on trunk. yay!

Comment 43

[Robert Kaiser]

creature turned up that I had forgotten to remove regus from makeall.pl files

Comment 44

[Robert Kaiser]

Attachment: fix up leftover regus references

http://lxr.mozilla.org/seamonkey/search?string=regus turns up 4 cases of left over "regus" references in xpinstall/packager, which are fixed by this simple patch.

This also should make creature go green.

Comment 45

[Robert Kaiser]

fixup is in as well, thanks!

Comment 46

[Scott MacGregor]

kairo, I'd be interested in porting this change to the ispdata Makefile.in:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=Makefile.in&branch=&root=/cvsroot&subdir=mozilla/mailnews/base/ispdata&command=DIFF_FRAMESET&rev1=1.9&rev2=1.10

that would mac movemail.rdf and dotmac.rdf start showing up for Thunderbird on the branch. Would that cause seamonkey problems for 1.8.1? If so I can wrap the changes in a thunderbird only ifdef...

Comment 47

[Robert Kaiser]

mscott:
This bug and fix is strictly trunk-only for SeaMonkey, and additionally, we have already frozen SeaMonkey locale strings (that includes where files live) for the whole 1.8.1[.x] (SeaMonkey 1.1.x) lifetime, so if you port anything of this to 1.8 branch, please make it |#ifdef MOZ_THUNDERBIRD|