C#6.0 have a string interpolation - a nice feature to format strings like:
var name = \"John\";
WriteLine($\"My name is {name}\");
The ex
An interpolated string evaluates the block between the curly braces as a C# expression (e.g. {expression}
, {1 + 1}
, {person.FirstName}
).
This means that the expressions in an interpolated string must reference names in the current context.
For example this statement will not compile:
var nameFormat = $"My name is {name}"; // Cannot use *name*
// before it is declared
var name = "Fred";
WriteLine(nameFormat);
Similarly:
class Program
{
const string interpolated = $"{firstName}"; // Name *firstName* does not exist
// in the current context
static void Main(string[] args)
{
var firstName = "fred";
Console.WriteLine(interpolated);
Console.ReadKey();
}
}
To answer your question:
There is no current mechanism provided by the framework to evaluate interpolated strings at runtime. Therefore, you cannot store strings and interpolate on the fly out of the box.
There are libraries that exist that handle runtime interpolation of strings.
According to this discussion on the Roslyn codeplex site, string interpolation will likely not be compatible with resource files (emphasis mine):
String interpolation could be neater and easier to debug than either String.Format or concatenation...
Dim y = $"Robot {name} reporting
{coolant.name} levels are {coolant.level}
{reactor.name} levels are {reactor.level}"
However, this example is fishy. Most professional programmers won't be writing user-facing strings in code. Instead they'll be storing those strings in resources (.resw, .resx or .xlf) for reasons of localization. So there doesn't seem much use for string interpolation here.
As already said in previous answers: you currently cannot load the format string at runtime (e.g. from resource files) for string interpolation because it is used at compile time.
If you don't care about the compile time feature and just want to have named placeholders, you could use something like this extension method:
public static string StringFormat(this string input, Dictionary<string, object> elements)
{
int i = 0;
var values = new object[elements.Count];
foreach (var elem in elements)
{
input = Regex.Replace(input, "{" + Regex.Escape(elem.Key) + "(?<format>[^}]+)?}", "{" + i + "${format}}");
values[i++] = elem.Value;
}
return string.Format(input, values);
}
Be aware that you cannot have inline expressions like {i+1}
here and that this is not code with best performance.
You can use this with a dictionary you load from resource files or inline like this:
var txt = "Hello {name} on {day:yyyy-MM-dd}!".StringFormat(new Dictionary<string, object>
{
["name"] = "Joe",
["day"] = DateTime.Now,
});
String interpolation is difficult to combine with localization because the compiler prefers to translate it to string.Format(...)
, which does not support localization. However, there is a trick that makes it possible to combine localization and string interpolation; it is described near the end of this article.
Normally string interpolation is translated to
string.Format
, whose behavior cannot be customized. However, in much the same way as lambda methods sometimes become expression trees, the compiler will switch fromstring.Format
toFormattableStringFactory.Create
(a .NET 4.6 method) if the target method accepts aSystem.FormattableString
object.The problem is, the compiler prefers to call
string.Format
if possible, so if there were an overload ofLocalized()
that acceptedFormattableString
, it would not work with string interpolation because the C# compiler would simply ignore it [because there is an overload that accepts a plain string]. Actually, it's worse than that: the compiler also refuses to useFormattableString
when calling an extension method.It can work if you use a non-extension method. For example:
static class Loca { public static string lize(this FormattableString message) { return message.Format.Localized(message.GetArguments()); } }
Then you can use it like this:
public class Program { public static void Main(string[] args) { Localize.UseResourceManager(Resources.ResourceManager); var name = "Dave"; Console.WriteLine(Loca.lize($"Hello, {name}")); } }
It's important to realize that the compiler converts the
$"..."
string into an old-fashioned format string. So in this example,Loca.lize
actually receives"Hello, {0}"
as the format string, not"Hello, {name}"
.
Assuming that your question is more about how to localise interpolated strings in your source code, and not how to handle interpolated string resources...
Given the example code:
var name = "John";
var middlename = "W";
var surname = "Bloggs";
var text = $"My name is {name} {middlename} {surname}";
Console.WriteLine(text);
The output is obviously:
My name is John W Bloggs
Now change the text assignment to fetch a translation instead:
var text = Translate($"My name is {name} {middlename} {surname}");
Translate
is implemented like this:
public static string Translate(FormattableString text)
{
return string.Format(GetTranslation(text.Format),
text.GetArguments());
}
private static string GetTranslation(string text)
{
return text; // actually use gettext or whatever
}
You need to provide your own implementation of GetTranslation
; it will receive a string like "My name is {0} {1} {2}"
and should use GetText or resources or similar to locate and return a suitable translation for this, or just return the original parameter to skip translation.
You will still need to document for your translators what the parameter numbers mean; the text used in the original code string doesn't exist at runtime.
If, for example, in this case GetTranslation
returned "{2}. {0} {2}, {1}. Don't wear it out."
(hey, localisation is not just about language!) then the output of the full program would be:
Bloggs. John Bloggs, W. Don't wear it out.
Having said this, while using this style of translation is easy to develop, it's hard to actually translate, since the strings are buried in the code and only surface at runtime. Unless you have a tool that can statically explore your code and extract all the translatable strings (without having to hit that code path at runtime), you're better off using more traditional resx files, since they inherently give you a table of text to be translated.
Interpolated strings can not refactored out from their (variable) scope because of using of the embedded variables in them.
The only way to relocate the string literal part is passing the scope bound variables as parameter to an other location, and mark their position in the string with special placeholders. However this solution is already "invented" and out there:
string.Format("literal with placeholers", parameters);
or some of advanced library (interpolating runtime), but using the very same concept (passing parameters).
Then you can refactor out the "literal with placeholers"
to a resource.