bug-groff
[Top][All Lists]
Advanced

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

[bug #61123] make macro package localization more robust


From: G. Branden Robinson
Subject: [bug #61123] make macro package localization more robust
Date: Tue, 7 Sep 2021 04:39:45 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

URL:
  <https://savannah.gnu.org/bugs/?61123>

                 Summary: make macro package localization more robust
                 Project: GNU troff
            Submitted by: gbranden
            Submitted on: Tue 07 Sep 2021 08:39:43 AM UTC
                Category: Macro - others
                Severity: 1 - Wish
              Item Group: New feature
                  Status: None
                 Privacy: Public
             Assigned to: gbranden
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

In a message to the groff dev list[1], I said:

> the groff 1.22.4 documentation told people that they had to be sure to
specify the localization macro package as the last -m argument on the command
line.  This felt fragile to me.

> It is not clear to me now why this might be the case.  I've been doing all
kinds of janitorial robustification over the past few years, and either that
or changes before I started working on groff made the claim inaccurate.

I figured out why it was there.  It involves using localization macro files
_with other macro packages_.  The string assignments (themselves indirected
through the \*[locale] string) need to be performed afresh when the groff
locale changes, and the conditionals run for me(7), mm, and ms (re-)executed.

It looks like one way to approach this would be to pull most of the content of
tmac/trans.tmac into a macro, perhaps with `.de1 reinitialize-localization` or
similar, and then not only have trans.tmac call the macro it just defined, but
also have the macro packages call that macro as part of their initialization.

Interesting test cases may involve setting the date (or not), and ensuring
that a localized date string is updated appropriately as the input language
changes.  A complicating factor is the ms package, which permits the argument
to its DA and ND macros to be something other than a date.  If the user calls
such macros, the argument should not be updated by a groff locale, because it
might not be a date at all.  Setting a package-specific flag will , I suspect,
take care of this.  If an ms document author calls DA/ND and it has
localizable content, they'll need to take care of it themselves when changing
languages.

[1] https://lists.gnu.org/archive/html/groff/2021-07/msg00018.html




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61123>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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