On 2/20/12 11:28 AM, Jose Armando Garcia wrote:
On Mon, Feb 20, 2012 at 2:37 PM, Andrei Alexandrescu
<[email protected] <mailto:[email protected]>>
wrote:

    On 2/20/12 10:16 AM, Nick Sabalausky wrote:

        "Andrei Alexandrescu"<[email protected]
        <mailto:[email protected]>>  wrote in message
        news:jhtq31$u8q$1@digitalmars.__com...


            Again, I think this thread clarified we need the
            "Variant[string] info;"
            member however we define the hierarchy.


        I disagree. I don't see a need for that.


    How would we address custom formatting of e.g. error messages?


This may not be D. Gettext says to solve it as follow:

throw new Exception(gettext("Cool English message at
%s.").format(DateTime.now()))

The gettext "compiler" goes through the code an generates all the
strings that need to be localized. The translation teams modifies those
string and you store them in file/map for that language. At runtime the
i18n library turns gettext(...) into a query into that map and returns
the actual localized string. There is a map for the entire process.

Localization can also be disable at compile time by making gettext a
template and generating a "noop" for that operation.

So this moves formatting from the catch point to the throw point. That's fine, but it forces the formatting effort upfront even when the message is not actually used and leads to duplication because each call site would need to provide the message entirely. I think it's worth investigating formatting at the catch site.

I have been thinking of making a module for i18n model after gettext but
taking advantage of D's language features. Is there some interest in this?

Yah, this would be of interest.


Andrei

Reply via email to