bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Texinfo translation error, texinfo_document domain


From: Gavin Smith
Subject: Re: Texinfo translation error, texinfo_document domain
Date: Sat, 29 Oct 2022 16:02:45 +0100

(trimming mailing list that you cannot post to if not subscribed)

On Sat, Oct 29, 2022 at 04:39:32PM +0200, Bruno Haible wrote:
> It sounds wrong to expect translators to use TeXinfo syntax for
> non-ASCII characters, for three reasons:
> 
> 1) Translator tools support the common (state-free) charset encodings,
>    namely UTF-8, ISO-8859-*, and so on. Not TeX with \, not TeXinfo with
>    @, not ISO-2022-*. PO files that expect TeXinfo syntax deny translators
>    from the ability to use their native input methods.
> 
>    I guess this is the reason why you don't see Chinese, Hindi, Vietnamese,
>    Armenian, etc. translations for texinfo/po_document/*.po.

UTF-8 is allowed and works.  See e.g. po_document/uk.po.

> 
> 2) Even for translators who are familiar with the TeXinfo syntax, the
>    TeXinfo syntax allows for mistakes like the one reported above, that
>    could not happen if UTF-8 was used for the encoding, in the translator's
>    workflow.

I remember supporting Texinfo in document strings was a significant
complication as we had to parse the results.  However, it works fine now
and would be hard to eliminate completely.

Currently there are some strings like

msgid "see {reference} in @cite{{book}}"

We'd have to work out if we could change it to

msgid "see {reference} in {book}"

instead, which may be possible, but not something that is a priority
just now.  (Maybe we can look into it after the next release.)

It should be fine to use 'œ' instead of @oe{}.  I'm not sure I completely
remember the reasoning behind using Texinfo glyph commands instead of the
character in the encoding.

https://lists.gnu.org/archive/html/texinfo-devel/2015-04/msg00007.html

Whatever the problem was in 2015, we worked it out.


> 3) This syntax reduces the functionality available in msgfmt. For example, in
>    pt_BR.po there is the message
> 
>      #: tp/Texinfo/Convert/DocBook.pm:1088
>      #, perl-brace-format
>      msgid "see section ``{section_name}'' in @cite{{book}}"
>      msgstr "veja se@,{c}@~{a}o ``{section_name}'' em @cite{{book}}"
> 
>    If this message was being checked by 'msgfmt -c', it would report an error,
>    because the translation has more variables ({c}, {a}, {section_name},
>    {book}) than the msgid. Thus I conclude that you have not enabled the '-c'
>    option of msgfmt, and thus the — would-be useful — perl-brace-format
>    argument checking does not happen.

If we ever stop having Texinfo in translated strings then it may be possible
to add the -c flag, but it doesn't seem like a major problem.
> 
> I would strongly suggest to request UTF-8 encoded PO files from the
> translators and convert them to TeXinfo syntax inside the TeXinfo build
> system.
> 
> Bruno
> 
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]