61627 - Need a mechanism to facilitate langpack bundling change

Status: RESOLVED WORKSFORME

(SeaMonkey :: Installer, defect)

Description

[tao]

Currently, to change the langpack bundling of the US build, we need to add or
modify the global installer script template for the core build and each
individual langpack.

We need a simpler mechanism to make the process more efficient and less error-prone.

Comment 1

[tao]

Let's address this in the earlier stage of the next release.

Comment 2

[Daniel Veditz [:dveditz]]

Need to relook, but think anything besides editing config.ini requires
architectural changes beyond the scope of what we're prepared to deal with right
now.  However, we have recently made adding/changing langpacks in the current
system easier.

Comment 3

[Daniel Veditz [:dveditz]]

Tao, we need more detail about what you want.

Comment 4

[Daniel Veditz [:dveditz]]

Reassigning to better facilitate triage of known quantities

Comment 5

[tao]

Hi, Dan:


I am thinking about having a template, langpack.jst, that could be parsed to
generate langxxx.jst (and then, langxxxx.js), config.ini, and makeall.pl so we
don't need to physically edit various files when changing language pack
bundling.

It will be a perl script similar to how you generate *.js from *.jst and
config.ini from config.it now.

Comments?

Comment 6

[Daniel Veditz [:dveditz]]

No time to do the scripting in my team; shouldn't be too hard for anyone vaguely
familiar with perl, just do some simple variable replacements the way the .jst
-> .js conversion is done now.

Comment 7

[tao]

Hi, Dan: Do you have plan for this in Buffy timeframe? If not, would you mind if
we take it? thx!

Comment 8

[Daniel Veditz [:dveditz]]

I don't mind, but work with curt. He's trying to design a system that will
eliminate any package names from makeall, and will instead use whatever is
exported to a certain build directory.

You would have to modify config.it, but that part's an easy variable replacement

Comment 9

[tao]

Thanks, Dan. ->juraj, CC curt. 

Comment 10

[[e-mail] (away - not reading bugmail)]

accepting

Comment 11

[[e-mail] (away - not reading bugmail)]

raising priority, I'll try to do this as my next work item for l10n

Comment 12

[[e-mail] (away - not reading bugmail)]

I have a fix which generates the langXXYY.jst files nicely

Actually, first things first.  Here are the complete set of build scripts which
I have been working on for reference: 
http://blues/users/curt/publish/GRE_Installer/sync_build/builds/seamonkey/

The changes I'm making to generate the intl jst's are in
http://blues/users/curt/publish/GRE_Installer/sync_build/intl_fix/seamonkey/

(If you want to grab this stuff it is all under \\blues\curt*\publish.)

So I added a GettingStarted() function to makeall.pl.  For mozilla, gre, and
mfcembed this is a noop.  For Netscape this calls into a function called
CreateIntlJst() for each jst file to be generated.  You can look at this
function in the files xpinstall\packager\build\cfgs\netscape.pl.  For a couple
example calls to CreateIntlJst() are commented out.  When we branch these lines
can be uncommented and more added for the intl xpi's which need to be created. 
(And it will be necessary to add the actual packages of files which need to go
into the xpi's as well, but I guess intl must be used to doing all that already.)

So, my assumption is that mozilla doesn't care about this functionality, so I
put CreateIntlJst() in the netscape specific perl script.  If I'm mistaken or
mozilla ends up needing the functionality in the future it will no big deal to
float that up into makeall.pl and leave the specific calls to it from
GettingStarted() in the product specific perl scripts.

Let me know what you think.


Curt

Comment 13

[Syd Logan]

--> toa, removing plus for reconsideration

Comment 14

[Fernando Cassia]

Speaking of langpacks, two questions:

1) Is there a bug already opened to bring back the NS 6.x functionality where
the browser's language pack was easily changed by going to View-> (now it's
about 5 click deep into edit->preferences ...)

2) One of the features I really liked in 6.0 was the ability to change themes
and language packs "on the fly". In other words, there was a warning displayed
briefly saying that some things might not look right initially, and that it was
best if the browser was restarted, but most of the time this wasn't needed and
the browser "redrawed" itself with the new theme / language pack.

3) Any chances of making a separate language pack / region pack for SOUTH
AMERICAN spanish? (as opposed to Spain's). There are too Spain-specific terms in
the current spanish language pack that makes the translation look bad, cheap,
and foreign. Microsoft has learned long ago to do separate editions (both of
software and its documentation) for Spanish-Europe (ES-ES) and Spanish-LA (Latin
America) (ES-LA).

(btw: I'm still waiting for the 7.01 spanish lang pack...). :o)

I volunteer to do the required changes to make the ES-ES language and region
packs into ES-LA, and maintain the changes. IF NS agrees to make me the
maintainer and make a "latin american spanish" build of future releases...

4) Who in management had the bright idea NOT to release separate language packs
for 7.x ? It was one of my strongest "selling points" for Netscape 6.2x

Ok, enough rant for a single comment. ;-)

I know most of this is off-topic for this bug, but feel free to email me
directly if you wish, or comment below, if your reply to me is related to this
langpack bug.

Regards

Fernando Cassia
Buenos Aires, Argentina

[e-mail]

Comment 15

[Rafael Ebron (:rebron)]

Installer triage team: nsbeta1-

Comment 16

[tao]

Hi, Bob: please reassign these i18n/l10n/l12y bugs accordingly. thx!

Comment 17

[Matthias Versen [:Matti]]

Seamonkey and Firefox are using a new NSIS based installer. resolving this old bug, please reopen if you still get this with the new installer