URL:
<http://gna.org/patch/?4455>
Summary: Replace R__() with per-source-file domain marking?
Project: Freeciv
Submitted by: jtn
Submitted on: Sun Jan 26 15:15:28 2014
Category: freeciv-ruledit
Priority: 5 - Normal
Status: Need Info
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Planned Release:
_______________________________________________________
Details:
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/POTFILES.in (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:
#define foostring() _("Some msgid")
In this case we want to fetch from freeciv.mo 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.
#define duptrans(s) fc_dupstr(_(s))
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:
#ifdef ALT_TRANSLATION_DOMAIN
#define _(String) dgettext(ALT_TRANSLATION_DOMAIN, String)
/* ... */
#else
#define _(String) gettext(String)
/* ... */
#endif
At the top of every source file in tools/ruledit:
#define ALT_TRANSLATION_DOMAIN "freeciv-nations"
#ifdef HAVE_CONFIG_H
#include <fc_config.h>
#endif
/* ... other include files ... */
#include "fcintl.h"
/* ... */
/* body of file */
main_window->setWindowTitle(_("Freeciv ruleset editor"));
/* ... */
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.
_______________________________________________________
Reply to this item at:
<http://gna.org/patch/?4455>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
