bugGNU roff - Bugs: bug #63076, [tmac] add Russian language support

 
 

bug #63076: [tmac] add Russian language support

Submitter:  Nikita Ivanov <nikitaivanov>
Submitted:  Sat 17 Sep 2022 05:41:41 PM UTC
   
 
Category:  Macro - others/general Severity:  1 - Wish
Item Group:  Feature change Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.24.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 10 Jul 2023 08:58:10 AM UTC, comment #20: 


commit 2a0b305357526b3596f7014983a4306bf9f737ab
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Mar 9 11:48:42 2023 -0600

    [tests]: Add Russian language support (7/7).

    * src/roff/groff/tests/localization_works.sh:
    * tmac/tests/e_ld-works.sh: Test it.

    Fixes <https://savannah.gnu.org/bugs/?63076>.  Thanks to Nikita Ivanov.

commit 1058ed9c474c9e0689c5c55670175236f8a3bfc5
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Mar 8 05:04:42 2023 -0600

    [docs]: Add Russian language support (6/7).

    * doc/groff.texi (Input Encodings, Manipulating Hyphenation):
    * doc/ms.ms (Language and localization):
    * man/groff_tmac.5.man (Localization packages, Input encodings):
      Document support for KOI8-R encoding and Russian language.

    * NEWS: Add item.

commit 6075a61c302f0187e6ef8b50198910d7af13ab6e
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Mar 8 04:40:33 2023 -0600

    [tmac]: Add Russian language support (5/7).

    * tmac/tmac.am (TMACNORMALFILES): Ship new Russian language support
      files.

commit b5d6dd6e7452620eed56199cd58387fe1ee8a2a4
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Mar 8 04:33:48 2023 -0600

    [tmac]: Add Russian language support (4/7).

    * tmac/koi8-ru.tmac: Rename this file...
    * tmac/koi8-r.tmac: ...to this.  There _is_ a "KOI8-RU" encoding, which
      appears to subsume KOI8-B and KOI8-U (by replacing more box drawing
      characters), but this file does not remap their values to applicable
      Unicode code points.
    * tmac/ru.tmac: Load the encoding file under its new name.

commit 4734956f1f6585b2a25037a8efe9604b45460ef6
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Mar 8 04:28:27 2023 -0600

    [tmac]: Add Russian language support (3/7).

    * tmac/hyphen.ru:
    * tmac/ru.tmac: Update editor aids so these files can be edited more
      intelligibly using GNU Emacs.  Annotate apparent problem with Vim's
      KOI8-R support.

commit 1700f24a29ef4cdb2e5ede0c899c10bb485727e8
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Mar 9 10:01:28 2023 -0600

    LICENSES: Add Russian language support (2/7).

commit f1584a51adb25841e90abbb7a0364701eb61d74f
Author: Nikita Ivanov <nikita.vyach.ivanov@gmail.com>
Date:   Wed Mar 8 20:54:47 2023 +0000

    [tmac]: Add Russian language support (1/7).

    * tmac/hyphen.ru: Add hyphenation patterns (encoded in KOI8-R).
    * tmac/koi8-ru.tmac: Add character encoding support.
    * tmac/ru.tmac: Add groff locale for Russian.


G. Branden Robinson <gbranden>
Group administrator
Fri 10 Mar 2023 10:15:13 PM UTC, comment #19: 

comment #17:

> Yes, although in English, style authorities conflict over whether em-dashes should get space around them, so groff does not mandate a policy.  Deciding this question may require consultation of multiple style authorities in Russian.

I did and this is what one of them states:

> You cannot transfer punctuation marks to another line, except for a dash after a period or after a colon before the second part of the interrupted direct speech.


It means that it's not always incorrect to put a line break before the dash. And I don't see it being possible to communicate the condition on whether to put a line break to groff. So I guess putting \~ is the only way.

comment #18:

> Setting this to "Ready for Test" since we don't really use that status.  In this case, it means I'd like you to test it, and also that it needs to be merged onto master (after 1.23.0 final is tagged).

I tried building it but encountered an error:


cp: cannot stat '../doc/groff.txt': No such file or directory
make[2]: *** [Makefile:14583: install-txt] Error 1
make[2]: Leaving directory '/home/nikita/aur/groff-git/src/groff-git/build'
make[1]: *** [Makefile:11924: install-am] Error 2
make[1]: Leaving directory '/home/nikita/aur/groff-git/src/groff-git/build'
make: *** [Makefile:11917: install] Error 2


I've fixed it by applying this patch (although, I'm not sure it's a correct solution):


diff --git a/doc/doc.am b/doc/doc.am
index cddc51907..9626dbb28 100644
--- a/doc/doc.am
+++ b/doc/doc.am
@@ -624,7 +624,7 @@ install-data-local: install-txt
 install-txt:
         -test -d $(DESTDIR)$(docdir) \
           || $(mkinstalldirs) $(DESTDIR)$(docdir)
-        cp $(top_srcdir)/doc/groff.txt $(DESTDIR)$(docdir)
+        cp $(top_builddir)/doc/groff.txt $(DESTDIR)$(docdir)

 install-data-local: install_infodoc
 install_infodoc: doc/groff.info


Other than that, the localization seems to be working. I've just discovered that the order of macroset includions on a command line matters: If I put -mru before -ms, ms strings are not localized. Maybe it should me documented on groff_tmac(5)?

I've read again documentation for the hyphenation pattern (which resides in tmac/hyphen.ru now) and it turns out that there is another hyphenation pattern file in the same package which is supposed to improve hyphenation for words that contain the letter "yo" (ё). I'm not exactly sure why they were not distributed in a single file. I think it should be included in groff as well.

(file #54471)

Nikita Ivanov <nikitaivanov>
Thu 09 Mar 2023 08:12:34 PM UTC, comment #18: 

Hi Nikita,

I've pushed these changes to groff's "post-1.23.0" branch.

https://git.savannah.gnu.org/cgit/groff.git/log/?h=post-1.23.0

Setting this to "Ready for Test" since we don't really use that status.  In this case, it means I'd like you to test it, and also that it needs to be merged onto master (after 1.23.0 final is tagged).

G. Branden Robinson <gbranden>
Group administrator
Thu 09 Mar 2023 03:52:20 PM UTC, comment #17: 

comment #16:

> comment #15:
> > Apparently it can.  In your example document, your use of the character ≈ (in KOI8, this is hex 0x97 or decimal 151) is rejected by GNU troff upon input.
> By mistake I included a literal em dash character () in the document. If I replace it with \[em], no error is raised after running groff -ww.


Ah, I see, the code point that was ≈ in KOI8-R is assigned to the em dash — in KOI8-RU.  But I note that your patch seems to support the former, not the latter--you do not have `trin` requests for є, і, ї, ґ, or ў.

That's not necessarily a defect; KOI8-R, in its alphabetic code points, seems to be fully compatible with KOI8-{B,U,RU} (at least) so it's a good basis from which to start groff support for Cyrillic languages.
 

> I've read tmac/LOCALIZATION and apparently you are not supposed to redefine the second string in ISODATE macro. I've attached a patch that fixes that.


Cool.  I'll integrate it with your earlier patch--I haven't pushed anything yet.
 

> The changes you made all seem correct to me, except for the revised version of my document (the fix should have been a

replacement of the character with \[em]; see the 1st paragraph).

I'll fix that--thanks!
 

> Speaking of an em dash character, it is used fairly often in Russian texts.


In English, too!

> I have noticed that quite frequently a line break is added before or after the character, which, as far as I know, is incorrect. I know it's fixable by adding no-break spaces before and after the character but it seems like there could be a more automatic solution.  Is it possible to somehow tell groff to avoid adding breaks in those cases (perhaps using .cflags request)?


Yes, although in English, style authorities conflict over whether em-dashes should get space around them, so groff does not mandate a policy.  Deciding this question may require consultation of multiple style authorities in Russian.

G. Branden Robinson <gbranden>
Group administrator
Wed 08 Mar 2023 08:54:47 PM UTC, comment #16: 

comment #15:

> Apparently it can.  In your example document, your use of the character ≈ (in KOI8, this is hex 0x97 or decimal 151) is rejected by GNU troff upon input.

By mistake I included a literal em dash character () in the document. If I replace it with \[em], no error is raised after running groff -ww.

I've read tmac/LOCALIZATION and apparently you are not supposed to redefine the second string in ISODATE macro. I've attached a patch that fixes that.

> I'm attaching a revised version of your document, and a stack of diffs I have pending after applying your patch.
>
> Let me know what you think.

The changes you made all seem correct to me, except for the revised version of my document (the fix should have been a replacement of the character with \[em]; see the 1st paragraph).

Speaking of an em dash character, it is used fairly often in Russian texts. I have noticed that quite frequently a line break is added before or after the character, which, as far as I know, is incorrect. I know it's fixable by adding no-break spaces before and after the character but it seems like there could be a more automatic solution. Is it possible to somehow tell groff to avoid adding breaks in those cases (perhaps using .cflags request)?


(file #54466)

Nikita Ivanov <nikitaivanov>
Wed 08 Mar 2023 11:23:20 AM UTC, comment #15: 


comment #13:

> > I guess the main things I'm curious about are how you solved the problem of KOI8-R having code points in the same space as C1 controls (which groff uses for internal purposes).
> I did not handle that case in any special way. The resulting document looks as it is supposed to (including the Cyrillic "a" characters (а), which C1 translates to). Or this problem can manifest itself in some unobvious way?


Apparently it can.  In your example document, your use of the character ≈ (in KOI8, this is hex 0x97 or decimal 151) is rejected by GNU troff upon input.

I'm attaching a revised version of your document, and a stack of diffs I have pending after applying your patch.

Let me know what you think.

(file #54463, file #54464)

G. Branden Robinson <gbranden>
Group administrator
Wed 08 Mar 2023 12:57:39 AM UTC, comment #14: 


comment #13:

> > I guess the main things I'm curious about are how you solved the problem of KOI8-R having code points in the same space as C1 controls (which groff uses for internal purposes).
> I did not handle that case in any special way. The resulting document looks as it is supposed to (including the Cyrillic "a" characters (а), which C1 translates to). Or this problem can manifest itself in some unobvious way?


Ah, I see--the answer is pretty obvious if I just look at a KOI8-R code chart instead of going by memory.

https://en.wikipedia.org/wiki/KOI8-R

All of the problematic code points (0x80-0x9F) are not alphabetic in KOI8-R.  In fact they're the sorts of things you wouldn't normally have in *roff input documents, or even most word-processed documents no matter what the formatter.

While I think it would be in order to caution the user that not every valid graphical code point in KOI8-R is acceptable groff input, for inputting text there will be no problem.  And preconv(1) can be used anyway.

There are established groff mechanisms for obtaining the symbols in KOI8-R 0x80-0x9F.  Several have groff special character names, some are best obtained using the eqn(1) preprocessor, and things like boxes are best done with tbl(1) tables or drawing commands (\D escape sequences).

This simplifies things a lot.  Again, finding the right place(s) to document the restriction on 0x80-0x9F will be important--but it looks like there are no serious technical challenges here.

G. Branden Robinson <gbranden>
Group administrator
Tue 07 Mar 2023 10:20:43 PM UTC, comment #13: 


> I guess the main things I'm curious about are how you solved the problem of KOI8-R having code points in the same space as C1 controls (which groff uses for internal purposes).

I did not handle that case in any special way. The resulting document looks as it is supposed to (including the Cyrillic "a" characters (а), which C1 translates to). Or this problem can manifest itself in some unobvious way?

Nikita Ivanov <nikitaivanov>
Tue 07 Mar 2023 09:49:06 PM UTC, comment #12: 

comment #11:

> > There, I have bad news--I'm afraid not.
> I probably should have replied way earlier. But anyway, I'm looking forward to see it being added in 1.23.1!


Me too!  I love having new features to brag on.  It takes a certain kind of person to get excited about 400+ bug fixes, 160 new automated tests, and greatly improved documentation, and that kind of person is not in the majority.  :)
 

> > It might become the basis of a unit test so we can be sure we keep Russian language support working.
> So, the next thing I should do is to write unit tests for the language macros, right?


We already have some.

You might look at the following files for inspiration.


tmac/tests/latin2_works.sh
tmac/tests/latin5_works.sh
tmac/tests/latin9_works.sh
tmac/tests/localization-works.sh


I guess the main things I'm curious about are how you solved the problem of KOI8-R having code points in the same space as C1 controls (which groff uses for internal purposes).  (I should look again at your patches.)

Ensuring that the character encoding stays sane is a foundational element.  Beyond that, apart from the hyphenation mode being right (which can be added to tmac/tests/localization-works.sh), I don't suppose there is a lot to test.

G. Branden Robinson <gbranden>
Group administrator
Tue 07 Mar 2023 09:41:18 PM UTC, comment #11: 


> There, I have bad news--I'm afraid not.

I probably should have replied way earlier. But anyway, I'm looking forward to see it being added in 1.23.1!

> It might become the basis of a unit test so we can be sure we keep Russian language support working.

So, the next thing I should do is to write unit tests for the language macros, right?

Nikita Ivanov <nikitaivanov>
Tue 07 Mar 2023 09:31:42 PM UTC, comment #10: 

comment #9:

> I've done my research and it turns out that usually no additional spacing is added after a sentence ending. This means that the patch I sent previously does not require any modifications.


Ok, cool.

> I've attached an example ms document that makes use of the language file.


This is helpful, thanks.  It might become the basis of a unit test so we can be sure we keep Russian language support working.
 

> If there a chance this addition will end up in the 1.23.0 release if the patch is correct and there is still an interest in adding the feature?


There, I have bad news--I'm afraid not.  It's taken quite a while to get 1.23 solidified for release, we've had 2 more release candidates, and I am hoping the next tag will be for 1.23.0 final.

Also, groff 1.23.0 missed the freeze for the next Debian stable release, so that sucks.

However, I very much do not want another four years to pass before we release groff again, and I don't see anything in your patch that would preclude it from a 1.23.1 release.  I'd like for that to happen 3 to 6 months after 1.23.0 final, whenever that happens.   (Our GNU maintainer Bertrand Garrigues has to do the tagging, official archive generation, and upload--he's delegated other release management tasks to me in preparation for me becoming the next maintainer.)

G. Branden Robinson <gbranden>
Group administrator
Tue 07 Mar 2023 09:19:19 PM UTC, comment #9: 

I've done my research and it turns out that usually no additional spacing is added after a sentence ending. This means that the patch I sent previously does not require any modifications.

I've attached an example ms document that makes use of the language file.

If there a chance this addition will end up in the 1.23.0 release if the patch is correct and there is still an interest in adding the feature?

(file #54451)

Nikita Ivanov <nikitaivanov>
Sun 23 Oct 2022 08:27:09 PM UTC, comment #8: 

Forgot to provide a link.

https://en.wikipedia.org/wiki/History_of_sentence_spacing#French_and_English_spacing

And me further clarify; using each of a pair of words to mean precisely opposite things is often a way to achieve lucidity.

What I mean is that what one speaker calls "widows", another calls "orphans", and vice versa; the same is, infuriatingly, true of "French" and "English" spacing.  So in practice these terms communicate nothing except a topic indicator.  ("Uhhh, something to do with lines of a paragraph being broken across pages.")

G. Branden Robinson <gbranden>
Group administrator
Sun 23 Oct 2022 08:24:22 PM UTC, comment #7: 


comment #5:

> Another question: Why do nearly all language macro packages set additional inter-sentence space to 0?


The short answer is English-language typography diverged from European practices over the 19th and 20th centuries.  With respect to this specific issue, practices within English-speaking communities have fragmented.

It is a deeply confusing issue.  As with "widows" and "orphans", "French spacing" and "English spacing" are each used to mean precisely opposite things.

Most European languages using the Latin alphabet appear to now predominantly use only one word space after sentence-endings.  I believe there is a European Union mandate (applicable to that organization's own official output only, but adhered to voluntarily by many private organizations for want of a different style manual) along these lines.

> Should the same be done in the Russian one?


I would consult one or authoritative style manuals for Russian language professional writing and typography.

G. Branden Robinson <gbranden>
Group administrator
Wed 28 Sep 2022 07:01:50 PM UTC, comment #6: 

Please review my patch groff-ru-1.patch. It includes translated strings for macro packages and hyphenation rules. The Cyrillic symbols are encoded in KOI8-R (koi8-ru.tmac adds support for the encoding).

(file #53764)

Nikita Ivanov <nikitaivanov>
Tue 20 Sep 2022 10:11:33 PM UTC, comment #5: 

Another question: Why do nearly all language macro packages set additional inter-sentence space to 0? Should the same be done in the Russian one?

Nikita Ivanov <nikitaivanov>
Tue 20 Sep 2022 08:22:25 PM UTC, comment #4: 

Thank you for so much helpful info!

I've noticed that if I enable hyphenation rules for Russian language with .hpf request, hyphenation for text written in English seems to stop working. However, it's not the case for French or German languages. Is it because those languages have similar hyphenation rules to English? Should I include English hyphenation rules in Russian hyphenation rules (or perhaps append English ones to Russian ones with .hpfa request) to make hyphenation work for both languages?

Nikita Ivanov <nikitaivanov>
Sun 18 Sep 2022 04:37:41 PM UTC, comment #3: 

original submission:

> I would love to help the project by adding support for Russian language (in a similar manner to Italian, German and so on, by providing hyphenation rules and strings in Russian for macro packages). The Russian language is spoken by around 258 million people in the world, so I think this addition may potentially help a lot of new and old groff users. What are your thoughts?


I see nothing objectionable here.

comment #1:

> When I wrote it, I forgot that the built-in fonts do not support Cyrillic symbols and you always has to use a 3rd-party font to write in Russian.


Yes, but that's true of Chinese and Japanese as well, yet we have the localization macro files zh.tmac and ja.tmac.

> So now I'm not sure if adding strings and hyphenation rules makes sense... Unless I also add Cyrillic symbols to the built-in fonts.


I don't think that is necessary.  I don't know if you saw my lengthy feedback to a recent request to support UTF-16-encoded fonts in grops, but some similar considerations are present.  People sometimes think they have to bite off more of a task than they really do.

Specifically, for Russian language support, the main things to check are the ones you need to customize: correctly localized strings, and correct hyphenation.

The really good news is that both are straightforward to verify for a fluent Russian speaker even without Cyrillic fonts installed.  All that is required is a partial understanding of GNU troff's device-independent output format ("grout", I like to call it) and either the ability to recognize Unicode code points for Cyrillic letters or a crude filter that will translate them for spot-checking at a terminal.

Consider the "simple example" from this message to the groff mailing list about a month ago.

If you can follow it, you are well on your way to knowing all the "grout" you need to to verify Russian language support.

For example, with a reasonable ru.tmac file in place, I expect to be able to produce output much like this using "groff -kZ -Tuf8".


x T utf8
x res 240 24 40
x init
x F -
p1
x font 1 R
f1
s10
V40
H0
md
DFd
Cu0431
H24
Cu043B
h24
Cu0430
h24
Cu0433
h24
Cu043E
h24
Chy
h24
n40 0
V80
H0
Cu0434
H24
Cu0430
h24
Cu0440
h24
Cu044F
h24
n40 0
x trailer
V2640
x stop


(If you're wondering how I got that, I gave groff input consisting of a Cyrillic word familiar to me, turned off adjustment, set the line length to 8n, and manually stuck in a hyphen where it seemed to make sense to me as an English speaker, knowing very little of the morphology of the Slavic-language specimen.)

(The above output can be given as input to grotty on a UTF-8-capable terminal and a terminal font with Cyrillic coverage, which is probably the practical means of checking Russian language support, but I wanted to illustrate how the task could be achieved even in a plain ASCII environment.)

Validating the localized strings is even easier; they simply need to be input in the source files in a natural way (UTF-8 and all) and proofread for spelling errors.  I cannot imagine a GNU troff failure mode where these input characters will be remapped or resequenced.

The "Manipulating Hyphenation" section/node of the groff Texinfo manual should prove useful for constructing the list of hyphenation codes.  There is an example in German already which illustrates the basic principle; each lowercase Cyrillic letter will need a "mapping" to itself, and then each uppercase counterpart can be mapped to the lowercase one.

The adaptation of TeX hyphenation patterns is the part that seems like it might be hardest to me.  All of our current hyphenation pattern files are in ASCII or an ISO-8859 encoding.  I don't know if iconv(1) is up to transforming them to a form that GNU troff's hyphenation pattern file reader is prepared to accept.

https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/env.cpp#n3784

Making groff support KOI8-R might be easier than getting it to interpret UTF-8-encoded hyphenation patterns, funny as that may sound.

On the other hand, we can integrate the macro file part of this first because it is independent and easy (saith I).  Without hyphenation pattern files, hyphenation simply won't be done.  That won't get us professional-grade typography, but it will improve significantly on the status quo.

(Mainly as a note to myself, one thing to check is what data type is used for hyphenation codes.  If it's a char, we should fix that.)

G. Branden Robinson <gbranden>
Group administrator
Sat 17 Sep 2022 06:23:44 PM UTC, comment #2: 

Someone has to do the work, preferably someone who has a basic understanding of three subjects: groff, the Russian language, and contributing to Free Software projects.  Professional skills are likely not required in any of these three areas, but some time and diligence are.

I doubt that any of the groff developers would be opposed to improving support for the Russian language (or any other language, no matter how many people speak it), if somebody interested takes the lead in developing the needed patches and helps with integration and ongoing maintenance.

Ingo Schwarze <schwarze>
Group Member
Sat 17 Sep 2022 05:55:27 PM UTC, comment #1: 

When I wrote it, I forgot that the built-in fonts do not support Cyrillic symbols and you always has to use a 3rd-party font to write in Russian. So now I'm not sure if adding strings and hyphenation rules makes sense... Unless I also add Cyrillic symbols to the built-in fonts.

Nikita Ivanov <nikitaivanov>
Sat 17 Sep 2022 05:41:41 PM UTC, original submission:  

I would love to help the project by adding support for Russian language (in a similar manner to Italian, German and so on, by providing hyphenation rules and strings in Russian for macro packages). The Russian language is spoken by around 258 million people in the world, so I think this addition may potentially help a lot of new and old groff users. What are your thoughts?

Nikita Ivanov <nikitaivanov>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #54471:  cyryoal.tex added by nikitaivanov (2KiB - text/x-tex)
file #54466:  ru-mm-fix.diff added by nikitaivanov (321B - text/x-patch)
file #54463:  groff-ru-test-revised-gbr.ms added by gbranden (3KiB - text/x-troff-ms)
file #54464:  ru-revisions.diff added by gbranden (10KiB - text/x-patch)
file #54451:  groff-ru-test.ms added by nikitaivanov (3KiB - text/x-troff-ms)
file #53764:  groff-ru-1.patch added by nikitaivanov (42KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by schwarze (Posted a comment)
  • -email is unavailable- added by nikitaivanov (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-07-10 gbranden StatusReady for Merge Fixed
        Open/ClosedOpen Closed
    2023-03-10 nikitaivanov Attached File- Added cyryoal.tex, #54471
    2023-03-09 gbranden StatusIn Progress Ready for Merge
    2023-03-09 gbranden Planned ReleaseNone 1.24.0
    2023-03-08 nikitaivanov Attached File- Added ru-mm-fix.diff, #54466
    2023-03-08 gbranden Attached File- Added groff-ru-test-revised-gbr.ms, #54463
        Attached File- Added ru-revisions.diff, #54464
        StatusNone In Progress
        Assigned toNone gbranden
    2023-03-07 nikitaivanov Attached File- Added groff-ru-test.ms, #54451
    2022-09-28 nikitaivanov Attached File- Added groff-ru-1.patch, #53764
    2022-09-18 gbranden CategoryGeneral Macro - others/general
        SummaryAdding Russian language to groff [tmac] add Russian language support
    2022-09-17 schwarze Severity3 - Normal 1 - Wish
        Item GroupNone Feature change

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code