Enrico Forestieri <[EMAIL PROTECTED]> writes: >> Using MSYS, I have built the libiconv package suggested by Michael and then >> gone on to build LyX using --with-included-gettext. configure finds >> libiconv and the build proceeds happily, but I find that the resulting .exe >> is unable to change the installed .po (.gmo) dynamically to the local >> locale. If I understood your message of some time ago correctly, you >> reported that your essentially-identical cygwin build was able to display a >> Polish LyX with native Windows LANG.
>> When I read the libiconv/gettext build docs, it seems that the build >> process is essentially circular. First build gettext, then libiconv, then >> gettext again. (Or start with libiconv, then gettext, then libiconv again.) >> So, I suspect that my build doesn't work as advertised because my build is >> incomplete. >> Before I invest time and effort into trying out my theory, can you explain >> in more detail just what you did to get this stuff working? > I suspect that this is an hardcoded path problem. The configure script > sets LYX_ABS_INSTALLED_LOCALEDIR to the directory $prefix/Resources/locale > and then this directory is hardcoded into the executable. > So, if LyX is installed in a different place than the $prefix dir, it will > be unable to find the files. Noooooo, there's nothing *wrong* with my build per se. All .po files (actually, the compiled .po files with .gmo extension I think) are found as expected. However, the Polish .po file is encoded using the ISO-????? encoding whilst Poles using Windows will be using the CP-1251 encoding or somesuch. My understanding is that we can convert dynamically between the two so long as we have a gettext-aware libiconv (and a libiconv-aware gettext). I seem to remember you stating that this dynamic conversion worked for you using a Cygwin-built LyX. I was trying to find out a little bit more about your setup. Do you use the libiconv and gettext compiled by Cygwin, did you compile your own? Etc, etc... Regards, Angus
