Need localization scheme for native resources




18 years ago
7 years ago


(Reporter: yinglinxia, Unassigned)




Firefox Tracking Flags

(Not tracked)




18 years ago
"Hardcoded" string in Mac "Netscape" binary rsrc.
   resource 'STR#' (1000, "CanRunStrings") {
      "You cannot run Ò" PACKAGE_NAME "Ó while another copy of Mozilla or    Netscape 6 is running. "
      "Ò" PACKAGE_NAME "Ó will now quit."
This need to be removed into language pack.


18 years ago
Keywords: l12y


18 years ago
Component: Browser-General → Localization
Assignee: asa → rchen
Ever confirmed: true
QA Contact: doronr → andreasb

Comment 2

18 years ago
Well, I should not own this bug. Ying, can you find out who is the owner?
Assignee: rchen → yxia

Comment 3

18 years ago added this string, assiagn to him, and cc who did r and sr.
Assignee: yxia → pchen
This can't be added to a language pack because this resource is used before
XPCOM is initialized. We would have to have a localization layer on top of
native resource mgr calls - which we don't.

Comment 5

18 years ago
This *cannot* be moved into a language pack, because the UI is shown before we 
have loaded any of the XP code. It happens really early on at load time, just 
like the progress dialog strings.

Comment 6

18 years ago
Seems we have to touch the rsrc to localize it, no other choice then.
Should we mark it as WONTFIX or INVALID?
With the current summary, it's invalid. If the summary were changed to "Need
localization scheme for native resources" it would at least be a valid bug.
Whether it's WONTFIX is up to pchen.

Comment 8

18 years ago
We didn't touch the binary for localization before, but with current situation, 
we have to do it again. Users get this message very often if they try to click 
our browser twice. My suggestion for future fix is, to make it same feature as 
Win32, which is, once you have a browser running whatever language it is, if 
you click another one, the current running one will be active, without starting 
the one you just clicked. I think this makes more sense than showing up this 

Comment 9

18 years ago
> My suggestion for future fix is, to make it same feature as Win32, which is

I agree and that's what I said on the bug that caused this. That's another
problem though and does not have to do with localization.

Even if we fixed that, there are and may be yet more cases in which we need to
show a localized string before XPCOM is initialized. So, again, I think the bug
WRT localization is that we don't have a scheme to have native resources in
multiple locales.

If you want to see a nice, transparent way of doing this on the Mac, check out
MacApp or ACS:


Comment 10

18 years ago
Thanks for the information.

We should avoid to put any localizable stuff in the binary. Like the current 
warning dialog for OS 7 and older, we never localize it because it's hard to 
track for l10n process, we assumed that not many users will see it.

Comment 11

18 years ago
How about splash screen progress strings? Every user sees those, and in future 
there will be more of them.

As for the dialog when you run a second copy of Netscape, I think just activating 
the running copy and then quitting the new copy is not a good solution, because 
the dialog also shows when Mozilla is running and you start Netscape 6, or vice 
versa. It's not always the same application; in fact, on Mac, you have to have 
started a *different* copy of the application to see this dialog.

Comment 12

18 years ago
Let's leave the discussion about what happens when you launch another copy of he
app out of this one. There's a bug for that elsewhere.

But, because of the existing native resources that we already use, in addition
to the ones we may have in the future, we should solve this. Out of curiosity, I
downloaded the latest ACS and they do have code for this in
ACS:Suites:toolbox:CMultiLocale.h/.cpp Their implementation is very complex and
requires much of the rest of the ACS framework which we don't want, but it is a
good reference.

Comment 13

18 years ago
By the way, as l10n engineers, we don't mind to touch the binary rsrc. But as I 
said, it's not very good for our l10n process, for example, we were not allowed 
to localize the splash screen because touching the bianry file is kind of risk, 
it will involve more qa work.

Sorry for taking you guys time on this kind of issue ;-)


18 years ago
QA Contact: andreasb → ruixu

Comment 14

18 years ago
marking p5, minor, and future
Severity: normal → minor
Priority: -- → P5
Target Milestone: --- → Future

Comment 15

18 years ago
marking nsbeta1. It would be great to get this one out of the way and fixed now.
Please let us know if you have the time to do this fix. thanks!
Keywords: nsbeta1

Comment 16

18 years ago
Paul, can we put all localizable stuff into a text file, or a seperate 
resource file, so we don't need to touch the app binary anymore for our 
localization? Thanks.
->default assignee
Assignee: pchen → rchen
Target Milestone: Future → ---

Comment 18

17 years ago
Simon, do you mind owning this bug? Or assign it to the right person. Thanks.
Assignee: rchen → sfraser

Comment 19

17 years ago
I change the title to reflect the need - we need to show a localized string 
(warning or error) before XPCOM is initialized.
Summary: Hardcoded string in rsrc → Need localization scheme for native resources


17 years ago
Blocks: 61378

Comment 20

17 years ago
I think we just need to be able to suck a file from a know location with name-
value pairs, like a properties file, and use that for early localized resources.
Severity: minor → normal
Priority: P5 → P4
Target Milestone: --- → mozilla1.0

Comment 21

17 years ago
Not going to get to this for 1.0
Target Milestone: mozilla1.0 → mozilla1.1alpha
Simon - Is this something you can get to before you leave?
Whiteboard: [adt3]

Comment 23

17 years ago
*** Bug 61378 has been marked as a duplicate of this bug. ***

Comment 24

17 years ago
Won't get to this before sabbatical.
Assignee: sfraser → rchen

Comment 25

17 years ago
it is in 

Comment 26

17 years ago
the code read it is in xpfe/bootstrap/nsNativeAppSupportMac.cpp

Comment 27

17 years ago
reassign to nhott and nsbeta1- this for now. 
Assignee: rchen → nhotta
Keywords: nsbeta1 → nsbeta1-

Comment 28

17 years ago
We can investigate a better way for MacOS X. I don't think we should spend time
to improve MacOS 9 support.
Target Milestone: mozilla1.1alpha → mozilla1.2alpha


17 years ago
Target Milestone: mozilla1.2alpha → ---
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".


16 years ago
OS: Mac System 8.6 → MacOS X
This bug hasen't been touched for years and is clearly unowned. Moving back to default assignee/QA so that people, who are watching those can accurately triage this bug.

Also resetting Priority, Target Milestone, Status Whiteboard and Status.
Assignee: nhottanscp → nobody
Priority: P4 → --
QA Contact: ruixu → localization
Whiteboard: [adt3]
Since this is once again targeted at an unsupported platform, and it hasn't really been changed since the original WONTFIX suggestion in 2003 or the 2008 suggestion for retriage, I'm going to suggest once again that this be resolved as WONTFIX, unless this is somehow still relevant?
Whiteboard: [CLOSEME WONTFIX 2012-01-08]
INCOMPLETE is as good as WONTFIX. The mac app bundle stuff changed drastically since back then.
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [CLOSEME WONTFIX 2012-01-08]
You need to log in before you can comment on or make changes to this bug.