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
