patchFreeciv - Patches: patch #4455, Replace R__() with per-source-file...

Show feedback again

patch #4455: Replace R__() with per-source-file domain marking?

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Sun Jan 26 15:15:28 2014  
Category: freeciv-ruleditPriority: 5 - Normal
Status: Need InfoPrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: Contains string changes: None

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


Sun Jan 26 15:15:28 2014, original submission:

Here's an idea. It might be a bad idea.
There's a good chance this gets rejected.

Currently we have strings in ruledit marked with R__() rather than _(), so that they fetch the translation from the correct mo-file at runtime.

There's an implicit requirement that R__() be used exclusively in a source files iff it's one of those listed in translations/ruledit/ (which is currently tools/ruledit/*), because only the latter is used to collect strings.

Using R__() outside those source files, or _() inside them, won't do the right thing, because the relevant strings will end up in the wrong compiled message catalog.

The actual requirement is thus that any literal text string which appears in tools/ruledit/* must end up passed as an argument to R__().

Already today, there's a complication with header files. There are several ways a header file outside the "ruledit" set of source files could in principle invoke one of the _() family of macros:

1. Some macro could invoke _() with a literal string:

In this case we want to fetch from as that's where the translation will be. This will work today.
(This case is probably rare.)

2. Literal string marked only with N_(). Not sure where this would be used.
If the corresponding () was in ruledit.c, it would need to be a () not a R__() to do the right thing.
Probably this doesn't happen in practice.

3. Macro invoked on string passed by caller.

In this case, you want to invoke R__() if the macro was invoked in a ruledit source file (on a string there), _() elsewhere.
Our current arrangements would get this wrong if ruledit/*.cpp hypothetically invoked either duptrans(R_N_("foo")) or duptrans(N_("foo")).

4. Like (3) but with inline functions. Same requirement.

So, here's my awful idea for getting rid of R__() (a goal which I think would make my life easier).

Since use of R__() follows source files, could we instead make the behaviour of _() and friends context-dependent?

In fcintl.h:

At the top of every source file in tools/ruledit:

This would keep current behaviour for invocations in source files. WRT header files I think the behaviour would be:

1. Changes from right to wrong. We'd have to outlaw this.
2. Makes it impossible rather than just tricky to get this right. We'd have to outlaw this.
3. Would change from wrong to correct behaviour automatically.
4. As 3, except I don't know if having inline function definitions which expand to different code in different source files is problematic.

I haven't attempted to survey use of _() family macros in header files to see which of these classes is most important.
My gut feeling based on no research is that 3/4 win, making this proposal a win.

WRT grand plans in patch #4190, if they ever come to fruition, this would be irrelevant; if all strings needed for a given executable end up in a single message catalog, then _() will always do the right thing without needing a context-dependent expansion.

Jacob Nevins <jtn>
Project Administrator


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

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by jtn (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    No Changes Have Been Made to This Item
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup