Need localization scheme for native resources

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
17 years ago
7 years ago

People

(Reporter: yinglinxia, Unassigned)

Tracking

({l12y})

Trunk
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 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.

Updated

17 years ago
Keywords: l12y

Updated

17 years ago
Component: Browser-General → Localization

Comment 1

17 years ago
moving
Assignee: asa → rchen
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: doronr → andreasb

Comment 2

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

Comment 3

17 years ago
pchen@netscape.com 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

17 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.
(Reporter)

Comment 6

17 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.
(Reporter)

Comment 8

17 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 
message.

Comment 9

17 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: http://developer.apple.com/tools/macapp/index.html


(Reporter)

Comment 10

17 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

17 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

17 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.
(Reporter)

Comment 13

17 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 ;-)

Updated

17 years ago
QA Contact: andreasb → ruixu

Comment 14

17 years ago
marking p5, minor, and future
Severity: normal → minor
Status: NEW → ASSIGNED
Priority: -- → P5
Target Milestone: --- → Future

Comment 15

17 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
(Reporter)

Comment 16

17 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.

Comment 17

17 years ago
->default assignee
Assignee: pchen → rchen
Status: ASSIGNED → NEW
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

Updated

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
Status: NEW → ASSIGNED
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

Comment 22

17 years ago
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
Status: ASSIGNED → NEW

Comment 25

17 years ago
it is in 
xpfe/bootstrap/nsMacVersion.r

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.
Status: NEW → ASSIGNED
Target Milestone: mozilla1.1alpha → mozilla1.2alpha

Updated

16 years ago
Target Milestone: mozilla1.2alpha → ---
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. 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".

Updated

15 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
Status: ASSIGNED → NEW
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]

Comment 32

7 years ago
INCOMPLETE is as good as WONTFIX. The mac app bundle stuff changed drastically since back then.
Status: NEW → RESOLVED
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.