[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
>
>
>
- Re: Texinfo translation error, texinfo_document domain, Bruno Haible, 2022/10/29
- Re: Texinfo translation error, texinfo_document domain,
Gavin Smith <=
- Re: Texinfo translation error, texinfo_document domain, Bruno Haible, 2022/10/29
- Re: Texinfo translation error, texinfo_document domain, Gavin Smith, 2022/10/29
- Re: Texinfo translation error, texinfo_document domain, Patrice Dumas, 2022/10/30
- Re: Texinfo translation error, texinfo_document domain, Bruno Haible, 2022/10/31
- Re: Texinfo translation error, texinfo_document domain, Patrice Dumas, 2022/10/31
- Re: Texinfo translation error, texinfo_document domain, Bruno Haible, 2022/10/31