[vim/vim] The function gettext() does not output the text of translated strings (Issue #11619)

75 views
Skip to first unread message

Restorer

unread,
Nov 25, 2022, 2:58:37 PM11/25/22
to vim/vim, Subscribed

  1. Place the MO file "hello_world.mo" in the directory "$VIMRUNTIME/lang/ru/LC_MESSAGES" such content
    msgid: "Hello, world!"

    msgstr: "Привет, мир!"

  1. Run the script file in any convenient way
   function Hello()

   echomsg gettext("Hello, world!")

   end function

   call Hello()

The message Hello, world! will be displayed.

However, if you put the lines

    msgid: "Hello, world!"

    msgstr: "Привет, мир!"

to file "vim.mo", then the translated text of the message will be displayed.

That is, the translated message in the file "hello_world.mo" cannot be output by the gettext() function.

This, in my opinion, is not entirely correct for the following reasons:

Firstly, a plug-in that contains strings intended for translation can be used by a limited number of people, and is not intended for widespread distribution. And there may simply be no access to the source file "vim.po".

Secondly, every time you "drag" a huge file "vim.mo" with a small plug-in not very optimal.

And, thirdly, there may be conflicts and inconsistencies between the contents of the file "vim.mo" supplied with some plug-in and file "vim.mo" supplied with the Vim program.

This situation is most likely due to the fact that the Vim gettext() function is
actually just a wrapper for GNU gettext, and the value "domaintext" for GNU gettext is hardcoded in the Vim code.

Accordingly, we would like the Vim gettext() function to meet the requirements specified in the section "The Language Implementor's View" of the GNU gettext documentation. To do this, as far as I understand, it is required that the following GNU gettext functions are implemented in the Vim program:
bindtextdomain() (partially in the Vim program)
and for OS Windows
wbindtextdomain()
and
bind_textdomain_codeset()
(also partially implemented in the Vim program)

Then the description in the Vim editor of the gettext() function could look like this:

    gettext({text}, [{path/}]{package} [, {codeset}])		         *gettext()*





	Translate String {text} if possible.

	This is mainly for use in the distributed Vim scripts.  When

	generating message translations the {text} is extracted by

	xgettext, the translator can add the translated message in the

	.po file and Vim will lookup the translation when gettext() is

	called.

	For {text} double quoted strings are preferred, because

	xgettext does not understand escaping in single quoted

	strings.

	The argument {package} specify the name of the MO file

	containing the translated text of the script messages. A good

	tone is to specify {package} the same as the name of the script.

	If the part {path} is not specified, then the file {package}

	will be searched in the $VIMRUNTIME/lang/<LANGUAGE>/LC_MESSAGES

	directory. The value <LANGUAGE> corresponds to the value

	LC_MESSAGES which can be found with the command

	`:language message`.

	The part {path} of the argument must be specified as an absolute

	path and end with the string <LANGUAGE>/LC_MESSAGES.

	The argument {codeset} specify the text encoding used when

	displaying translated script messages. If this argument is

	omitted, the encoding set in the 'encoding' parameter is used.

	The argument {codeset} must be set as specified in the section

	|ecndoding-values|. The conversion of the text of the translated

	messages will be executed in accordance with the procedure

	described in the section |charset-conversion|.


Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/11619@github.com>

Bram Moolenaar

unread,
Nov 27, 2022, 3:34:56 PM11/27/22
to vim/vim, Subscribed

Please read the help for gettext() again: It is only intended for the distributed files, nothing else.

You can't put "msgid" and "msgstr" in a .mo file, these belong in a .po file, which has to go through various tools to create a .mo file that is then properly named and placed in the right directory.

I think what you actually ask for is a mechanism for plugins to support translations. This requires picking a unique name for the plugin. In the gettext docs you link to this is referred to as PACKAGE. This is described in the section
"4.10 Preparing Library Sources".

bindtextdomain (PACKAGE, LOCALEDIR);

And then for the translation use:

#define _(String) dgettext (PACKAGE, String)

This requires a lot of work, some additional builtin functions, tools to do the text extraction (like xgettext
but for Vim script), a script or Makefile to turn the .po file into a .mo file, instructions on how to install the plugin
in a way that the .mo files end up in the right place, etc.

Perhaps some of this already exists somewhere, but it's a big feature to add, and once plugin authors start using it then it should keep working, since making translations is a lot of effort, you don't want to redo it when the tools change.

The title of this issue doesn't cover this. You can either adjust the title to something like "add feature for plugins to support translations", but it's probably better to take the useful info out of this issue and create a proper feature request, then close this one.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/11619/1328334342@github.com>

Restorer

unread,
Nov 28, 2022, 1:22:42 PM11/28/22
to vim/vim, Subscribed

I'm sorry for my English, it's not my native language. This is machine translation.

You can't put "msgid" and "msgstr" in a .mo file, these belong in a .po file, which has to go through various tools to create a .mo file that is then properly named and placed in the right directory.

Bram, yes, of course, it was assumed that before getting into a .mo file, these lines would get into a .po file.
And already this text file .po will be converted by the tool msgfmt to binary .mo file.
I just omitted all these preparatory steps, assuming that whoever is doing this knows it already.

I think what you actually ask for is a mechanism for plugins to support translations. This requires picking a unique name for the plugin. In the gettext docs you link to this is referred to as PACKAGE. This is described in the section
"4.10 Preparing Library Sources".

Yes, that's what I'm talking about. The Vim editor can support translations for third-party plug-ins.
Thank you that, despite my clumsy presentation and poor English, you understood everything so accurately.

This requires a lot of work, some additional builtin functions, tools to do the text extraction (like xgettext
but for Vim script), a script or Makefile to turn the .po file into a .mo file, instructions on how to install the plugin
in a way that the .mo files end up in the right place, etc.

Perhaps some of this already exists somewhere, but it's a big feature to add, and once plugin authors start using it then it should keep working, since making translations is a lot of effort, you don't want to redo it when the tools change.

I'm not a real programmer, but I also understand that this is a fairly large amount of work.
That this is not only and not so much the coding itself, but also a detailed description, support and maintenance.
And of course I don't expect it to appear right tomorrow. I expect that you will do this over time.
Moreover, even if a small part has already been done as an initial stage. I mean the scripts for the optwin.vim file.
In addition, I thought that part of the work involving text extraction (xgettext), preparation.po files and their conversion to .mo files are left to the developers of plug-ins.
The Vim editor itself assumes the ability to display translated text from the .mo file supplied with the plug-in through its built-in functions.

It remains only to understand how much this will be in demand by plug-in developers and users.
But it is possible that it has not been in demand until now because there was no such possibility in the Vim editor, and there was no such functionality in the Vim editor because it was not in demand by developers.
In any case, I would not refuse such an opportunity, although I am almost developing plug-ins. But there are plug-ins for which I would like and could translate into another language.

The title of this issue doesn't cover this. You can either adjust the title to something like "add feature for plugins to support translations", but it's probably better to take the useful info out of this issue and create a proper feature request, then close this one.

Yes, Bram, I realized that it is better to create another request to create additional functionality. I'll do that.

Прошу извинить за мой английский, это не мой родной язык. Это машинный перевод.

You can't put "msgid" and "msgstr" in a .mo file, these belong in a .po file, which has to go through various tools to create a .mo file that is then properly named and placed in the right directory.

Брам, да, конечно, предполагалось, что прежде чем попасть в .mo файл, эти строки попадут в .po файл.
А уже этот текстовый .po файл и будет преобразован посредством инструмента msgfmt в двоичный .mo файл.
Я просто опустил все эти подготовительные шаги, полагая, что тот, кто этим занимается, знает это и так.

I think what you actually ask for is a mechanism for plugins to support translations. This requires picking a unique name for the plugin. In the gettext docs you link to this is referred to as PACKAGE. This is described in the section
"4.10 Preparing Library Sources".

Да, именно об этом я и говорю. Возможность поддержки редактором Vim переводов для сторонних подключаемых модулей.
Спасибо, что, несмотря на моё корявое изложение и на плохом английском, Вы так точно всё поняли.

This requires a lot of work, some additional builtin functions, tools to do the text extraction (like xgettext
but for Vim script), a script or Makefile to turn the .po file into a .mo file, instructions on how to install the plugin
in a way that the .mo files end up in the right place, etc.

Perhaps some of this already exists somewhere, but it's a big feature to add, and once plugin authors start using it then it should keep working, since making translations is a lot of effort, you don't want to redo it when the tools change.

Я не настоящий программист, но и я понимаю, что это достаточно большой объём работы.
Что это не только и не столько само кодирование, но ещё и подробное описание, поддержка и сопровождение.
И конечно я не рассчитываю, что это появится прямо завтра. Я рассчитываю, что Вы это сделаете со временем.
Тем более что, пускай и малая часть, уже сделана как начальный этап. Я имею в виду скрипты для файла optwin.vim.
К тому же я полагал, что часть работы затрагивающей извлечение текста (xgettext), подготовку .po файлов и их преобразование в .mo файлы отдать на откуп разработчиков подключаемых модулей.
Сам же редактор Vim берёт на себя возможность через свои встроенные функции отображать переведённый текст из .mo файла, поставляемый с подключаемым модулем.

Остаётся только понять насколько это будет востребовано разработчиками подключаемых модулей и пользователями.
Но, возможно, что это не было до сих пор востребовано потому, что такой возможности не было в редакторе Vim, а в редакторе Vim не было такого функционала, потому что не было востребовано разработчиками.
Во всяком случае, я бы не отказался от такой возможности, хотя почти разрабатываю подключаемые модули. Но есть модули, для которых я хотел бы и мог бы сделать перевод на другой язык.

The title of this issue doesn't cover this. You can either adjust the title to something like "add feature for plugins to support translations", but it's probably better to take the useful info out of this issue and create a proper feature request, then close this one.

Да, Брам, я понял, что лучше создать другой запрос на создание дополнительного функционала. Я так и сделаю.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/11619/1329545522@github.com>

Restorer

unread,
Nov 28, 2022, 2:30:39 PM11/28/22
to vim/vim, Subscribed

Closed #11619 as completed.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/11619/issue_event/7906190431@github.com>

Restorer

unread,
Nov 28, 2022, 2:30:39 PM11/28/22
to vim/vim, Subscribed

A new feature request has been created #11637


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/11619/1329635803@github.com>

Reply all
Reply to author
Forward
0 new messages