Alternative placeholder syntaxes

[lime]

Background:

Some i18n tools (e.g. Tolk, different translation services) attempt to detect the default %{key} syntax, and warn you if the same placeholder is missing from the translation. Understandably, they often stumble at the syntax used by It, as %{link:potato} differs from %{link:pomme de terre}.

Proposal:

What do you think about enabling an alternative syntax, that would be "backwards-compatible" with conventional i18n interpolations? It would of course be optional, e.g. enabled in an initializer.

My first thought would be to pass the text content in separate parentheses after the normal interpolation, e.g. %{link}(potato) or %{link}[potato]. Maybe there are other viable options as well?

I'd be ready to develop this feature, but I thought I'd ask for opinions first to see if someone else considers it an idea worth pursuing.

[iGEL]

At first sight I like the idea. However, I wouldn't use parenthesis, as they are very common in many languages and there might be legit cases or easy-to-fall-in mistakes, where a parenthesis directly follows a key.
Why not %{key}{translation}? %{key}[translation] could also be fine - it looks a bit like Markdown, but it's different.

I hope there aren't any edge cases we haven't thought of. Of course it should be still possible to nest the interpolations like in the README and %{key} {translation} (key not directly followed by translation) shouldn't do anything to {translation}. Please add tests for that.

The user has to choose one syntax, enabling both shouldn't be possible, and it should default to the current one.

[lime]

Why not %{key}{translation}? %{key}[translation] could also be fine - it looks a bit like Markdown, but it's different.

Yep, either looks good. I'm leaning more towards the square brackets, but I don't think it really matters. The only issue with curly brackets I can think of is if any of the previously mentioned tools have goofed up their regexen to not stop at the first closing bracket or something... 😬

Of course it should be still possible to nest the interpolations like in the README and %{key} {translation} (key not directly followed by translation) shouldn't do anything to {translation}. Please add tests for that.

The user has to choose one syntax, enabling both shouldn't be possible, and it should default to the current one.

I'm happy to see we think the same way. ^_^

[coldnebo]

In our case, we are using MemoQ which supports Rails default interpolation, but 'locks' anything inside the %{...}, making it impossible for translators to actually edit the text within the link.

Here's what their editor looks like with xml (html snippets in yaml look similar):

In the edit pane, tags are abbreviated into little chevrons that are locked segments and not editable.

alternative syntax

I'm toying with the idea of an alternate interpolation syntax as well that might work with MemoQ's existing assumptions, something like:

key: Here is <it:link>a page</it:link>.

In this case, the chevrons would be "it:link", but "a page" would still be editable.

Maybe this bends the style away from Rails into something else... so I can understand if you don't want to go that direction. I do like the markdown-like syntax, but I'm not sure if MemoQ currently supports markdown dialects. In the past they didn't.

change MemoQ?

MemoQ does support an old, but flexible format for defining segment rules:

• https://en.wikipedia.org/wiki/Segmentation_Rules_eXchange

I suppose another solution on our end would be to figure out how to modify their .srx file to work with the "it" gem as it currently works, or with the markdown-like syntax being proposed. If I go this way, I'd be happy to share the results.