Re: vim + win + utf-8 => I'm lost

On 03/12/09 09:18, Mojca Miklavec wrote:
> And while at it just a tiny question: why do I need to provide menu
> translation in three different encodings? Vim is very good in
> converting from one encoding to another, so I see no reason for
> duplication. German translation (and other Latin1 languages) just
> provides a single file written in Latin1 and then other encoding just
> include that file (since Latin1=Unicode in the first 256 characters
> that is not a problem at all).
>
> For Slovenian I need to provide 3 different files with exactly the
> same strings (exactly the same content), just in different encodings
> (much easier to mess up when updating translations). Vim could be able
> to do the conversion on the fly.
>
> Thanks,
> Mojca
>

IF it is compiled with +multi_lang +multi_byte +iconv (on Windows,
usually +multi_byte_ime/dyn and +iconv/dyn) AND the iconv library (on
Windows, the iconv.dll or libiconv.dll) can be found. A "Normal" build
of Vim would come with +multi_lang but -multi_byte (and therefore
-iconv, which relies on multi_byte) so it could give you menus in Polish
or Slovenian in some appropriate 8-bit encoding, but NOT in UTF-8 and
NOT translate them from UTF-8. It also could not translate from one
8-bit encoding to a different 8-bit encoding, just because the
encoding-conversion code was left out at compile-time.

Now since UTF-8 is "the way of the future", you could write your
translations in UTF-8 and translate them automatically at compile-time
if the appropriate code appears in the appropriate Makefile; but if you
provide translations in just one 8-bit encoding, how would Vim (when
running in UTF-8) know which encoding it must translate from at run-time
for which language?

Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
214. Your MCI "Circle of Friends" are all Hayes-compatible.

--
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php