[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nano-devel] Doc translations with po4a
Re: [Nano-devel] Doc translations with po4a
Fri, 01 Aug 2014 13:58:28 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
Am 01.08.2014 09:38, schrieb Mihai Cristescu:
> Hello Mario,
>> There's no decision made yet whether to ship the man and texinfo
>> translations in
>> one template. For the time being, do nothing. And if you can't wait,
>> continue on
>> translate the texinfo stuff based on the pot file generated with my script,
>> is easy to split the file later, if needed.
> OK, then I wait for the official template released by nano-devel.
>> Good idea. The last update was almost ten years ago, and it is always better
>> have the UI strings (almost) complete before working on docs. If you do that,
>> please convert the file encoding from ISO-8859-2 to UTF-8 please.
> Of course UTF-8 is the coding I am using since long time. The problem
> with the ISO-8859-2 is that even if it is described as being the
> coding for Romanian language among other languages, I consider it is
> Because it contains some characters (letters) which are not accepted
> officially by the Romanian academy. These wrong characters are:
> ş = U+015F (Cedilla)
> Ş = U+015E (Cedilla)
> ţ = U+0163 (Cedilla)
> Ţ = U+0162 (Cedilla)
> They are probably from Turkish language, not Romanian. The good thing
> is that those characters are correctly displayed with the standard
> font in framebuffer terminal (not X) in most of the distributions.
> But the correct characters accepted are:
> ș = U+0219 (comma)
> ț = U+021B (comma)
> Ș = U+0218 (comma)
> Ț = U+021B (comma)
> which are available in UTF-8 extended coding.
> With the standard font of the terminal in framebuffer the correct
> characters are not correctly displayed, thus the supporting fonts with
> these characters have to be configured (like Terminus).
> In this moment there is a mess with the coding of the strings in many
> packages, not only nano. Most of them are ISO-8859-2.
What's the problem now to migrate to UTF-8? As I correctly understand, the
character encoding iso-8859-2 is problematic, not UTF-8. Well, Romanian users
have to reconfigure their terminals, but this issue has to be solved on upstream
level, not by distributors.
>> Regarding po files for texinfo, maybe you meant the TP domain
>> "help2man-texinfo"? This is the first attempt at all to get texinfo docs of a
>> GNU project translated. Once the latest version 1.46.1 appears in Archlinux,
>> install it and test the behavior of the docs. Translations are included for
>> Polish, Ukrainian and German. As far as I can see, the package is already
>> available in Debian Sid and Mageia Cauldron.
> No, sorry no related to help2man.
> Actually what is the purpose of the texinfo strings for nano?
> I see that there are:
> - strings for man (nano.1, rnano.1, nanorc.5), which generate also
> html doc files
> - strings for nano interface
> - texinfo stands for ???
Each GNU software has to have a Texinfo manual. This is the reference
documentation (see  for the HTML version). It is also installed in the
system, so you can run "info nano" in a terminal to get that version. Mostly the
texinfo docs contain more and extended info about the programs of that project,
and in some cases I know about that upstream maintainers forward the user to the
texinfo docs in doubt, because the manpages are not always in sync with the
current behavior of the programs. Moreover, the texinfo source gives a better
Besides that, GNU projects have traditional Unix man pages, but this is not
mandatory. However, Debian needs them, so some projects generate their man pages
with help2man, which uses the output of --help and --version the create the
groff source text.
> In my opinion we should translate as much as possible in one single
> template, not only man/interface, but I don't know if creating the
> template and reversing to the source documents is too complex task, so
> it is nano-devel decision what the template will contain.
I agree with you. Although the formatting of groff and texinfo sources is very
different and I don't expect any synergy effects, it would help translators to
keep the terminology in sync. In my opinion we should merge the templates. That
way we would also gently force translators to work on both documentation
But I wouldn't mix the UI and doc templates. UI files (*.mo) will then be
generated using the whole file, which will place also compiled doc strings there
were actually only UI strings are expected. This could cause side effects which
we can't imagine yet. Moreover, most translators make (still) a difference
between the importance of UI and doc translations, I don't want to annoy them.