Clytie pretty much has it right about what's going on with NSIS and Unicode
support.  When we were looking for Unicode support in an Open Source
installer package, we looked into NSIS and found no desire to support
Unicode on the part of the developers.  After two months of work to get
Unicode support into the NSIS codebase and offering it to the NSIS team, I
thought they'd take it but to my surprise they didn't.  They didn't like
certain things about my implementation and held it at that.  They talked
about how they'd like to do it better.  I said, "Fine.  Here's my code, you
can use it to get started."  It's been ten months and if you look at the
latest posts, they are still talking about how they can do better.  I don't
think they've actually done any development towards Unicode support.  (I
hope I am wrong.)

My goals were pretty straightforward when I added Unicode support to NSIS.
I wanted only Unicode support since all the software we wanted to ship was
Unicode software.  However, in the interest of making sure that this
codebase can be easily integrated into the main NSIS trunk, I made sure that
the same codebase can build the ANSI version of NSIS with just a macro
define during the build.  So with the same codebase you can build the ANSI
version of NSIS which will create an installer that works on Win9x and also
the Unicode version of NSIS which will run on Win2000+.  As for
maintainability, I have been keeping the Unicode NSIS in sync with the main
one in my spare time.  It usually takes a few hours to do so allowing me to
release the Unicode version usually within a week of the main NSIS's new
release.  That should speak to its viability as a project and adoptability
by the main NSIS team to go forward with the integration with my source
code.

In order to make the solution attainable, I made some decisions they
probably don't like -- for example, I only guarantee that the source code
can be built on msvc 8.0.  I didn't have time to try to compile on every C++
compiler they support.  I also decided that in order for this to work, the
internal strings must all be Unicode as well, which means the strings being
passed to the plugins must also be Unicode.  So I modified the plugins
source to build both Unicode/ANSI versions.  I made it so that the scripts
themselves must be Unicode.  We wanted to do mixed language strings in the
same installer.  This would be impossible or next to impossible if we kept
the scripts ANSI and tried to somehow convert to Unicode during the
installer compilation.  And Unicode-only languages wouldn't work since they
don't have ANSI codepages.
So I made some tough decisions that not everyone likes but got the project
to completion.  And as Clytie mentioned, lots of big open source projects
are adopting the solution as well.  So can I say for certain that this will
be incorporated into the main "official" NSIS?  I don't know.  Maybe it
won't.  Will they eventually come out with Unicode support in an "official"
NSIS?  I hope so.  But we all have been repeatedly told not to hold our
breaths.  So for now, my "unofficial" NSIS version is the only version that
supports Unicode and probably will be for the forseeable future.

As for the Debian team, it's up to you to decide whether to use what's
available now or to wait for something more official.

- Jim
On Sat, Jul 5, 2008 at 8:21 AM, Robert Millan <[EMAIL PROTECTED]> wrote:

>
> #489374 is the new bug, for nsis.  Please update the CC to it.
>
> Don't CC to #489218 anymore!
>
> On Sat, Jul 05, 2008 at 09:05:56PM +0930, Clytie Siddall wrote:
> > To Robert Millan, Debian developer for win32-loader
> > Cc: Jim Park, developer of NSIS Unicode; this bug at the BTS; NSIS
> > package address
> >
> > On 05/07/2008, at 7:58 PM, Robert Millan wrote:
> > >
> > >On Fri, Jul 04, 2008 at 11:11:46PM +0930, Clytie Siddall wrote:
> > >>>
> > >>>Is this a fork/branch of NSIS?  In that case, I'm afraid we can't
> > >>>use your
> > >>>translation untill Unicode support is merged (either in upstream or
> > >>>in the
> > >>>Debian package).
> > >>
> > >>NSIS Unicode is actually a separate project. The main NSIS project
> > >>refuses to support UTF-8, despite years of increasingly desperate
> > >>requests from the languages that require it (like Vietnamese). In the
> > >>end, this guy had to start his own project to solve the problem. He
> > >>always uses the latest NSIS code, but adds his modifications so it
> > >>supports UTF-8.
> > >
> > >From the link in their site to forum discussion about merging this
> > >in NSIS,
> > >it doesn't seem like they refuse to, but simply have concerns about
> > >minor
> > >things like which charset to use for examples, etc.  Are you sure
> > >this isn't
> > >going to be merged in the near future?
> >
> > I've CC'd Jim so he can explain this better. All I know is that we
> > translators have been formally requesting UTF-8 support in the main
> > NSIS project for _years_, at least 3 years in my case. The NSIS
> > project has repeatedly said that they "have no intention of supporting
> > UTF-8". If they are finally changing their mind, that's great, but I
> > wouldn't count on it.
> > >
> > >
> > >A problem with switching completely to UTF-16 is that this seems to be
> > >incompatible with Windows 98 (believe it or not, there are many
> > >users of
> > >this program who run it under Windows 98).  Is it possible to keep it
> > >multi-charset just like now, but using UTF-16 only for the languages
> > >that
> > >need it?
> >
> > Again, Jim can answer this better. I don't actually run Windows
> > myself, but nearly all my users do, so I translate a lot of software
> > which runs on Windows. I agree that older systems have to be supported
> > in some way, since in third-world countries people often can't afford
> > modern systems. (I've talked to developers in India, for example,
> > whose computers are extremely old and only held together by spit and
> > prayer. I remember losing touch with one developer because his
> > makeshift hardware repairs (involving string and sticky-tape) had
> > fallen apart, and that meant he no longer had computer access.)
> > >
> > >
> > >>OpenOffice.org has just started using NSIS Unicode, to support all
> > >>the
> > >>languages otherwise left out in the cold, and Mozilla also use it. I
> > >>should talk to Christian Perrier about this, because it's really an
> > >>i18n matter. But I thought you should also be concerned, since you're
> > >>packaging Windows installer software.
> > >
> > >It isn't really up to me.  If the functionality is in Debian, and is
> > >usable
> > >(see my concern above), I have no problem with using it.  You should
> > >also
> > >talk with Paul Wise (the maintainer of nsis in Debian);  I'm cloning
> > >this
> > >bug for you.
> >
> > OK, if Jim doesn't mind providing the info, I'm happy to help get
> > Unicode NSIS into Debian. I can't package it, but I can help join some
> > of the dots. (Note: I will be unavailable for some time soon [1-2
> > weeks?] due to medical treatment but hope to be able to participate
> > again afterwards.)
> >
> > from Clytie
> >
> > Vietnamese Free Software Translation Team
> > http://vnoss.net/dokuwiki/doku.php?id=projects:l10n
> >
> >
> >
>
>
>
> --
> Robert Millan
>
> <GPLv2> I know my rights; I want my phone call!
> <DRM> What good is a phone call… if you are unable to speak?
> (as seen on /.)
>

Reply via email to