Question: How to effectively manage HTML, DRY, and whitespace with Makara? about makara HOT 9 CLOSED

In general, splitting those translations up to DRY them out is bad.

Languages don't all inflect those the same way, and you create an invisible coupling between the translation for the button and the referencing translations. It feels like a good idea to DRY it out, but the invisible coupling is worse: it makes it very hard to refactor or update the translations, because you can't tell where they're used. Word order can vary across languages -- not important in this case, but in other similar cases (seemingly the same case to an English speaker) will be more problematic.

from makara.

Now, the inserting into HTML is more problematic, since that's definitely a concern you want to avoid.

from makara.

Thanks for your response!

Re: DRY: I agree that splitting up translations is bad! In the example above, like I said and you reiterated, the sentence structure changes across languages so breaking the string up piecemeal simply doesn’t work.

However, I should still be able to quote or reference complete strings (e.g., “Buy Now” should only need to be defined once, and I should be able to quote that text within other strings without copy+pasting it), reuse proper nouns (e.g., product or company names), and maintain a single source of truth for common grammar strings (e.g., common.grammar.colon = {0}: {1} in enUS, {0} : {1} in frFR with a non-breaking space, and {0}：{1} in zhCN with no whitespace at all).

Again, the examples I gave are all taken from a previous real-world project that covered 14 locales, including zhCN, zhTW, and koKR. I’d like to know if the same results are possible with Makara, and if so, how I can achieve them.

from makara.

Where do you fall on the spectrum of "directness is most important" and "lack of repetition is most important"?

I'm not sure I can give a good answer outright, but I'm trying to take these concepts into account for future developments, and to figure out what the best way is in the existing structure.

from makara.

I’m not sure I understand why I’d have to sacrifice one for the other. Perhaps I’m assuming something different by “directness”… would you be willing to clarify with an example?

from makara.

By directness, "how many references do I have to chase to read a string?" vs dry "how many times is this string repeated?"

It's hard to read something like "This{colon}{Brandname}" where Brandname is "Product{colon}The Greatest" -- how many entries do you have to look at to read, vs how many entries do you have to look at to update?

I find that they're directly antagonistic concerns. Repetition fixed by making references leads to indirection. The upside is that it's easier to propagate changes; the downside is that searching for "What emitted 'Product: The Greatest'?" gets hard, because it's no longer literal, but built.

from makara.

Ah. So again, I’m coming from a Java localization background where all properties are globally available and references are numeric. So the localization tool itself is not bound to either end of the spectrum: that decision is in the hands of the localization engineer.

For example, if I wanted to localize “This: Product: The greatest” I could write a new property like:

brand.name = {0}: {1}: {2}

And pass in the three pieces as a single argument to a message function, like this:

msg("brand.name", ["This", {brandname}, "The Greatest"])

Alternately, I could use the common grammar strings and write something like this:

msg("common.grammar.colon", ["This", msg("common.grammar.colon", [{brandname}, "The Greatest"])])

So one is arguably easier to read and one is arguably more DRY, but the tool itself doesn’t enforce one over the other.

from makara.

Alright. Sounds like some flexibility and not enforcing one end of the spectrum is a good idea.

That said, that last example hard-codes order, so it won't actually fly.

from makara.

True, not a great example. 😄 For that specific case I’d personally prefer the first option where order is defined by the arrangement of the properties, not the order of the arguments (for example, a different locale could use brand.name = {1}: {0}: {2}).

As you said, flexibility is a good idea.

Thanks again for your time!

from makara.