Was never a fan of _("some string {1}.", someArg), feels a bit unnatural and also:
_ has other connotations in JS, generally for unused variables.
Even if it doesn't, feels like lodash has already claimed that sigil, and frappejs makes use of lodash which leads to some mild confusion.
The design I'm thinking of will augment translation to take advantage of template strings. As of now the sigil is T.
Here's a preview of the API design:
// To obtain a translated string
T`The value of amount can't be ${amount}`.s
// To provide context
T`The value of amount can't be ${amount}`.ctx('sale').s
// `s` is not strictly required because of toString, so:
T`The value of amount can't be ${amount}`
// 't' is used when the class is not required, also allows backwards compatibility
frappe._ = t;
_("The value of amount can't be {}", amount)
Using a class for translation can allow other sorts of augmentations. For example, applying text decorations such as bold or italics to args or some string segments.
Note: This is just the frontend of the translation API, still need to think about the backend.
Was never a fan of
_("some string {1}.", someArg), feels a bit unnatural and also:_has other connotations in JS, generally for unused variables.lodashhas already claimed that sigil, andfrappejsmakes use oflodashwhich leads to some mild confusion.The design I'm thinking of will augment translation to take advantage of template strings. As of now the sigil is
T.Here's a preview of the API design:
Using a class for translation can allow other sorts of augmentations. For example, applying text decorations such as bold or italics to args or some string segments.
Note: This is just the frontend of the translation API, still need to think about the backend.