Closed Bug 343505 Opened 19 years ago Closed 19 years ago

Conversion from UTF-8 to locale codepage of locales.nsi can fail

Categories

(Firefox :: Installer, defect)

Product:
Firefox
Component:
Installer
Version:
2.0 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: robert.strong.bugs, Unassigned)

Details

The options here are to specify -cs when converting locales.nsi or writing to a new file the relevant lines from locales.nsi to a new file.
I think I INVALIDED this one in bug 343468 comment 11. Or rather, http://lxr.mozilla.org/mozilla1.8/source/toolkit/mozapps/installer/windows/nsis/preprocess-locale.pl#54 already does what comment 1 suggests as second alternative.
It doesn't create a new file from it and we need it to be read by NSIS so we can set the UI images appropriately for RTL. It is configurable since the images may be fine as is for LTR and RTL and we have chosen to have different LTR and RTL images. This shouldn't affect l10n and I'll check how NSIS handles this without conversion.
Ok, so this bug turns into a slightly different direction. locales.nsi is still never converted to a codepage, the generated nlf.in is. I see that http://lxr.mozilla.org/mozilla1.8/source/browser/installer/windows/nsis/installer.nsi#93 is used for http://lxr.mozilla.org/mozilla1.8/source/browser/installer/windows/nsis/installer.nsi#134. That indicates that there is no internal variable for RTL that would be set from baseLocale.nlf, is that so? http://nsis.sourceforge.net/Docs/Chapter4.html#4.10.3 mentions $(^RTL), maybe we could use that? I have the feeling that nothing should really happen to the compiler when it sees garbled encoded strings ;defined for some non-used vars. Even more so as I would expect all locales to suffer from a ;define encoding problem in installer.nsi. Sadly, it's almost 3am here, so I won't be running tests on this.
Axel, I'm verifying whether it works properly at this moment. Please don't worry about this and get some sleep... I'll take care of this if anything needs to be done.
(In reply to comment #4) > That indicates that there is no internal variable for RTL that would be set > from baseLocale.nlf, is that so? > http://nsis.sourceforge.net/Docs/Chapter4.html#4.10.3 mentions $(^RTL), maybe > we could use that? I believe this happens later on > I have the feeling that nothing should really happen to the compiler when it > sees garbled encoded strings ;defined for some non-used vars. Even more so as I > would expect all locales to suffer from a ;define encoding problem in > installer.nsi. I suspect nothing will need to be done for this bug... I'm just being cautious.
NSIS works fine with this as is. Resolving -> invalid
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.