39100 - psm_text.properties should be under locale directory

Status: VERIFIED WONTFIX

(Core :: Security, defect, P3)

Description

[rchen]

Should PSM (Cartman) be under chrome? If we want to keep different locales for 
PSM, psm_text can't be overwritten.

Comment 1

[rchen]

Bob Lord, is it possible fixed in beta2? Any comment?

Comment 2

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 3

[John Unruh]

Marking Wontfix. Installing or reinstalling a new commercial build overwrites 
the PSM files with new ones. Installing or reinstalling a new version of PSM 
with Mozilla overwrites the old PSM files. I don't see a reason for the PSM 
files to be in a subdirectory of Mozilla or Netscape 6.

Comment 4

[tao]

Will Seamonkey client reference this file in runtime? 
Is PSM part of Seamonkey's runtime component?

If yes, we need to use chrome:// to reference this file which requires this
file to live in chrome directory.

Comment 5

[Katsuhiko Momoi]

Where is this file located in terms of the path structure
currently? The file contains localizable strings in it.

Comment 6

[rchen]

Now it is under \program files\common files\Netscape Shared\Security\UI. 

Comment 7

[David P. Drinan]

The seamonkey client does not reference the psm_text.properties file. Marking 
this bug wontfix.

Comment 8

[John Unruh]

Verified.

Comment 9

[Allan Masri]

As I interpret this bug, the objection to placing localization of 
psm_text.properties in the language pack is a structural one: Since psm does not 
interact with seamonkey, the properties file should not be included in 
seamonkey. What we are concerned with here is the ability of a person to change 
a language pack and thereby change the psm language. This ability exists 
independently of the structure of the product. The functionality could be added 
in at least two ways:

(1) At installation time. Whenever a user installs a language pack, the 
psm_text.properties file on the disk is automatically replaced with one that is 
stored in the language pack. This assumes that the installer knows where the 
psm directory is located. The problem with this approach is that the wrong 
language may be installed -- the user wants the language pack, but doesn't want 
psm in the new language. The workaround is to reinstall the language pack with 
the preferred language. 

(2)At restart. When the user restarts seamonkey after selecting a new language 
pack, the psm_text.properties on disk could be replaced.

(3)on psm launch. When the user launches psm, it could look for its properties 
file in the langpack jar, or the file could be loaded by seamonkey and passed to 
psm when it launches.

The main problem here is that all localizable material, with the exception of 
psm, is in the language pack. psm should conform with the rest of the product. 
There may be obstacles to overcome, but the goal of multilingual support is an 
important one, and one that we as a group have decided to pursue.

Comment 10

[John Unruh]

Marking wontfix, since PSM 2.0 is in the builds now. Please open new bugs if 
internationalization is still a problem.

Comment 11

[John Unruh]

Verified.