Closed Bug 457797 Opened 11 years ago Closed 11 years ago

Build process uses wrong iconv parameters for locale eo

Categories

(Mozilla Localizations :: eo / Esperanto, defect)

x86
Windows NT
defect
Not set

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 305039

People

(Reporter: etrapani, Unassigned)

References

()

Details

The Windows build fails at the line:

iconv -f UTF-8 -t CP1252 > ../../dist/xpi-stage/locale-eo/updater.ini
iconv: (stdin):3:6: cannot convert


The problem is that Esperanto uses ISO-8859-3 and CP1252 relates ISO-8859-1.
The same command, with -t ISO-8859-3 works.

For now, in order to build, we will have transliterate those files, but its not pretty.  Can the -t parameter be changed?
Flags: wanted-firefox3.1?
http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/installer/windows/charset.mk#1

Your locale controls the character set that is used.
Component: Build Config → eo / Esperanto
Product: Firefox → Mozilla Localizations
QA Contact: build.config → esperanto.eo
Version: Trunk → unspecified
Good, we could change it.  But there seems to be no equivalent windows code page for iso-8859-3 in the list.  It seems that for windows it should be CP853.  Do you think it would work?  I don't see CP853 in the iconv -L output in my box ...

Any ideas on how to solve this?  ISO-8859-3 is used by Maltese and Esperanto.
I have seen this before somewhere, and I didn't find a code page for Esperanto either that's supported by iconv.

I thought we figured that we should just transcribe the installer to latin script, or do I recall that wrongly?
Yes, you've seen it before :)  Bug 415589.  I didn't know I had to do it for hg too and, following your advice I filed a bug.

Transliterating is only a hack and it works. But I was trying to find a way to solve the issue properly.  I guess that sooner or later other locales will face the same problem, the coverage of windows code pages is smaller than that of iso.
The right fix is to get rid of the code page restriction. That's another bug, not sure if we're going to get that into 3.1.
When we have a fully unicode installer, we don't need all this transliteration any more... we could encode the ini files in UTF8 and convert to real unicode.

We could probably do that in updater right now.
Are there any open bugs about the code page restriction or the unicode installer?   I couldn't find them. It'd be nice to be able to follow them to know when to revert to full unicode.
This should be fixed now on both the mozilla-central (trunk) and mozilla-1.9.1 (1.9.1 branch for Firefox 3.1, etc.) by bug 305039. Eduardo, can you verify this is fixed?
I just checked it.  It works for the latest nightly build.  What happens to 3.0.x?  Will it be fixed there too?
Bug 305039 might get fixed on 3.0.x depending on the risk as decided by the 3.0.x release drivers as well as the time and resources available to fix it on 3.0.x.

Resolving this bug as a duplicate of bug 305039 since that removed the conversion to ANSI.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 305039
Flags: wanted-firefox3.1?
Status: RESOLVED → VERIFIED
No longer depends on: 305039
You need to log in before you can comment on or make changes to this bug.