On Feb 20, 2012, at 11:12 AM, Nick Sabalausky wrote:
>
> ----------------------------------------------------
> class Exception
> {
> Variant[string] info;
> }
> class FooException
> {
> string fooName;
> int fooID;
> bool didBarOccur;
>
> this(string fooName, int fooID, bool didBarOccur)
> {
> this.fooName = fooName;
> this.fooID= fooID;
> this.didBarOccur= didBarOccur;
>
> info["fooName"] = fooName;
> info["fooID"] = fooID;
> info["didBarOccur"] = didBarOccur;
> }
> }
> ----------------------------------------------------
>
> If so, then I don't see any usefulness of "Variant[string] info" other than
> to start treating exceptions like JS's abomination of an "object" (Or at
> least AS2's objects anyway - not 100% certain how much of AS2 is taken from
> JS). If not, then could you clarify what you meant?
>
> In either case, I am interested to hear in more detail how you see
> "Variant[string] info" being used to address i18n. I haven't really dealt
> with a lot of i18n myself.
Localized error messages are typically generated by a localization team and
placed in some sort of a lookup table, indexed by language and error code. Say
the code is roughly like this:
displayLocalizedError(Exception e) {
auto t = loadTable(e.info["lang"]); // info["lang"] returns "ja" for
japanese, etc.
string m = t.findMessage(typeid(e).toString);
writeln(buildLocalizedMessage(m, e.info));
}
Where m (in english) may be something like:
"Saving to {LocationType} {!LocationName} failed because the destination is
full."
The message is parsed and when {LocalizationType} is encountered, the parser
knows to replace it with another localized string indexed by "LocationType".
Then {!LocationName} is replaced by e.info["LocationName"], which is specific
to the actual error that occurred. In essence, each line that has to be
localized has a monetary (and time) cost for doing so, so error lines are
reused when possible. Then specifics that may or may not themselves be
localized are potentially pasted in to generate the final message.
