Loading ...
Sorry, an error occurred while loading the content.

Re: how to get "gettext" work for Mac-Compilation?

Expand Messages
  • Benji Fisher
    ... It looks as though the version I compiled has -gettext as well. On the system I am using now (not the same as the one I used to compile vim) which
    Message 1 of 6 , Jun 25, 2002
    • 0 Attachment
      On Tuesday, June 25, 2002, at 05:44 PM, Dirk Zimmermann wrote:

      > Hi,
      >
      > I compiled 6.1.100 on my Mac (X 10.1.5) and it works fine, but the
      > language support doesn't work. After many different compilations I found
      > out, that the problem would be, that gettext is switched of. So, I
      > looked at the output of ./configure and it says.
      >
      > [...]
      > checking for NLS... gettext() doesn't work
      > [...]
      >
      > Does someone know how to get it work?

      It looks as though the version I compiled has -gettext as well. On
      the system I am using now (not the same as the one I used to compile
      vim) "which gettext" returns /sw/bin/gettext . This means that it must
      have been installed by Fink, probably when I was installing something
      else.

      By "language support," do you mean extended fonts, or
      translationsd, or something else? I try to compile in as many features
      as I can, but there is a lot of stuff I do not use myself...

      I suggest you join the vim-mac mailing list, if you have not
      already done so, and move this thread there.

      HTH --Benji Fisher

      http://homepage.mac.com/fisherbb/index.html
      http://fink.sourceforge.net/
    • Sébastien Pierre
      ... Yes, and Vim makefile does not look into /sw for includes or libraries. This would be a great thing to make the makefile be aware of /sw, I could then
      Message 2 of 6 , Jun 25, 2002
      • 0 Attachment
        Le mercredi 26 juin 2002, à 01:12 AM, Benji Fisher a écrit :

        > It looks as though the version I compiled has -gettext as well.
        > On the system I am using now (not the same as the one I used to compile
        > vim) "which gettext" returns /sw/bin/gettext . This means that it must
        > have been installed by Fink, probably when I was installing something
        > else.

        Yes, and Vim makefile does not look into /sw for includes or libraries.
        This would be a great thing to make the makefile be aware of /sw, I
        could then easily write a Carbon GVim package for Fink.

        > By "language support," do you mean extended fonts, or
        > translationsd, or something else? I try to compile in as many features
        > as I can, but there is a lot of stuff I do not use myself...

        I think he meant "encoding support". This would be great if the Mac-vim
        makefile would look if gettext() is available, because the alternate
        implementation using Cocoa i18n text services does not seem to work.

        -- Sébastien

        --
        «Il vaut mieux suivre une voix stupide que l'on connait,
        plutôt qu'une intelligente que l'on ne connait pas.»
        <http://www.type-z.org> -- No comment on Jacques C.
      • MURAOKA Taro
        I have improved MacOS-X s gettext() already. I wrote gettext() emulation layer with Carbon s CFBundle (this is standard MacOSX resource mechanism). Using
        Message 3 of 6 , Jun 26, 2002
        • 0 Attachment
          I have improved MacOS-X's gettext() already. I wrote gettext()
          emulation layer with Carbon's CFBundle (this is standard MacOSX resource
          mechanism). Using this we can write a message translation file for
          one language.

          That format is different from *.po, and required encoding is MacUnicode
          (may be big endian). I wrote some perl script, and it require iconv.
          I tested it for only Japanese. Because, I don't use with any other
          languages. If you would be interested and want to test it, I cound place
          it on my web site, please tell me.

          Here is a screen shot:
          http://www.kaoriya.net/testdir/mac_ja_msgmenu.jpg
          It shows a result of :intro in Japanese, and also there are Japanese
          strings in the menu and title-bar.


          > makefile would look if gettext() is available, because the alternate
          > implementation using Cocoa i18n text services does not seem to work.

          Do you mean my previous patch?

          http://www.kaoriya.net/testdir/VimMacOSXIconvMakeSet.tar.bz2

          Hmm. It works properly for Japanese encodings.
          Something are strange.
          ----
          MURAOKA Taro <koron@...>
        • Sébastien Pierre
          ... I think so as I tested it right after your announce. To be sure that encoding conversion work you can edit a file with fileencoding=latin1 and
          Message 4 of 6 , Jun 26, 2002
          • 0 Attachment
            Le mercredi 26 juin 2002, à 11:09 AM, MURAOKA Taro a écrit :

            >> makefile would look if gettext() is available, because the alternate
            >> implementation using Cocoa i18n text services does not seem to work.
            >
            > Do you mean my previous patch?
            >
            > http://www.kaoriya.net/testdir/VimMacOSXIconvMakeSet.tar.bz2

            I think so as I tested it right after your announce. To be sure that
            encoding conversion work you can edit a file with "fileencoding=latin1"
            and "fileencoding=macroman" that contains an "é" or any accentuated
            character. Then edit your file with OS X standard vi in terminal. You
            should have the same file for latin1 as the one edited with terminal.

            I think that a good way to solve the problem would be to look for a fink
            installation and if iconv() is availaible. If so, then iconv should be
            used by GVim so that encodings would work properly.

            -- Sébastien

            --
            «Too old to be alternative, too alternative to be old.»
            <http://www.type-z.org> | Robert Smith, talking about his epitaph.
          • MURAOKA Taro
            ... Ah. my patch has no entry for default latin1. So it would be fail when try to convert encoding between macroman and latin1 . I ll fix and test it. I
            Message 5 of 6 , Jun 26, 2002
            • 0 Attachment
              > I think so as I tested it right after your announce. To be sure that
              > encoding conversion work you can edit a file with "fileencoding=latin1"
              > and "fileencoding=macroman" that contains an "e" or any accentuated
              > character. Then edit your file with OS X standard vi in terminal. You
              > should have the same file for latin1 as the one edited with terminal.

              Ah. my patch has no entry for default latin1. So it would be fail when
              try to convert encoding between "macroman" and "latin1". I'll fix and
              test it. I attempt to use "ISOLatin1" for alias of "latin1".
              # "ISOLatin1" is one of encodings which MacOSX supported.

              > I think that a good way to solve the problem would be to look for a fink
              > installation and if iconv() is availaible. If so, then iconv should be
              > used by GVim so that encodings would work properly.

              I don't think so. Windows is very poor at encoding conversion, so using
              external library dynamically (iconv.dll) could become a good solution on
              Windows. This is similar way what you suggested.

              But, MacOSX has very powerful encoding support. User should be allowed
              to convert without any other external libraries. An external library is
              not always available on system, it must be installed by user. It's
              slightly trouble. But MacOSX API is always there.

              Using MacOSX's API wouldn't be easy way, but I think it would be enough
              worth to try and work on it.
              ----
              MURAOKA Taro <koron@...>
            • Sébastien Pierre
              ... yes, your solution seems to be the most coherent one. Maybe in the meantime it would be cool to use iconv, so that I could use CarbonVim instead of XVim.
              Message 6 of 6 , Jun 26, 2002
              • 0 Attachment
                Le mercredi 26 juin 2002, à 03:50 PM, MURAOKA Taro a écrit :

                >> I think that a good way to solve the problem would be to look for a
                >> fink
                >> installation and if iconv() is availaible. If so, then iconv should be
                >> used by GVim so that encodings would work properly.
                >
                > I don't think so. Windows is very poor at encoding conversion, so using
                > external library dynamically (iconv.dll) could become a good solution on
                > Windows. This is similar way what you suggested.
                >
                > But, MacOSX has very powerful encoding support. User should be allowed
                > to convert without any other external libraries. An external library is
                > not always available on system, it must be installed by user. It's
                > slightly trouble. But MacOSX API is always there.
                >
                > Using MacOSX's API wouldn't be easy way, but I think it would be enough
                > worth to try and work on it.

                yes, your solution seems to be the most coherent one. Maybe in the
                meantime it would be cool to use iconv, so that I could use CarbonVim
                instead of XVim. For the moment I am bound to use XVim because I need to
                write documents in latin-1 (working with other developers/documents in
                french processed by typesetting engine, etc.)

                can't wait for your next patch :)

                -- Sébastien

                --
                «My friends says we're like the dinosaurs, only we are doing
                ourselves in much faster than they ever did.»
                <http://www.type-z.org> -- Porno For Pyros, Pets
              Your message has been successfully submitted and would be delivered to recipients shortly.