Andy and I are getting ready to ensure SkySpark is localized across the code base, so I'm planning to knock out the previously feature of a special syntax in string interpolation for localization.

That was a great discussion, and I think we are all in agreement that having the ability to inline the English value for a localized property is probably worth its weight in gold. It makes localization trivial and lets developers easily do the right thing.

This is my proposed syntax for localized string interpolation:

"$<some.key>"       =>  Env.cur.locale(<enclosing-pod>, "some.key")
"$<somePod::key>"   =>  Env.cur.locale(Pod.find("somePod"), "key")
"$<key=My Value>"   =>  automatically adds key=My Value into en.props

The compiler would handle all of this during normal build cycle. It would be an error for a given key to declare a value in multiple places - each key must have one authoritative definition either in en.props itself or in exactly one interpolated string.

Can enclosing-pod work on the staitc scope?

I do hard-code in static scope:

instance scope : Pod.of(this).log
static scope : Pod.find("enclosingPodName").log

With the proposed syntax would it be possible to have JohnDG seconded inlining (last post)? Having

try 
{
  // a complex call
} catch (InternalErr e)
{
  report("$<err.io:Cannot open file ${name} in ${dir}>")
}

while still being able to override that in en.props as

err.fopen := "Can't open configuration file $0 in directory $1"

would so much better than

try 
{
  // a complex call
} catch (InternalErr e)
{
  report("$<err.io>", name, dir)
}

where (just because the key is not descriptive enough) the dev can't immediately say what parameters are needed or even what kind of error is reported to a user.

Can enclosing-pod work on the staitc scope?

Yes, but it will be some compiler magic that actually uses type literals for efficiency.

With the proposed syntax would it be possible to have JohnDG seconded inlining (last post)?

Here are my thoughts on trying to pass arguments into localized string values. Basically it is more hassle then it is worth. I think in the last ten years of writing localized apps, I've used that feature maybe a couple times. So I don't think it is worth the extra complexity. In Fantom this is done much easier like this:

report("$<err.io=Cannot open file:>$file $<err.dir>: $dir")

My native language has quite different word order from English (than let's say German or Spanish) so I guess I used it a bit more. But I agree that the simple approach can work well. It is usually sufficient to form statements as snippets with colons, brackets and parentheses instead "proper" sentences.

I'd still rather have a default than an automatic insertion (or both):

• I don't need to ensure that the default it is still unique (hunt other occurences),
• some message is still present for a dev.

When I see

report("$<err.io>$file $<err.dir>: $dir")

I'd probably have to search for $<err.io=> in code or en.props to get a clue. With defaults it would be more readable (even though the resulting message might be different).

The proposed plan is that you can specify a default value exactly once (either in a string literal or in en.props itself). If it is specified more than once it would be a compile time error.

The other option is to allow duplicates but only flag them as an error if they have different values.

Like most things I think exactly once check is the safest because it is the most restrictive, and allows us to change our mind later without breaking backward compatibility.

The code message should be a local override. The define once approach won't be nearly as useful.

Consider a large team where the developer writes the initial code with the inline message. Later, either during development or after deployment, a separate team of UI advisors come along and customise the message to make it more readable/understandable. That team will generally know nothing about programming, nor should they. They just need to know the keys.

The code message should be a local override. The define once approach won't be nearly as useful.

I agree that some of this based on how development teams are organized. For example we create all the English text used, but customers do localization in the field and those translations might or might not get packaged back into the pod file.

Although I am not sure having different values in code and en.props is necessarily a good thin. In some respects that is a social and build pipeline issue. My gut instinct is that we start off strict for now and require one definition. That gives us flexibility to open things up in the future. But if we make it too loose goosey now, we can't ever go back.

Promoted to ticket #1273 and assigned to brian

Ticket resolved in 1.0.56

This feature is wrapped up.

Once the build is complete, the following new sections in docs cover this feature:

• Literals
• Localization