The code example should rather be an example of what not to do. This method of concatenating different parts of sentences would fall short for any language where the adjective and noun change the form depending on each other and the context (ex. cases). Most Slavic languages make heavy use of this concept. The solution is to just have the full sentence as a single string and let the translation team write it out in its entirety. Avoid interpolating nouns, adjectives, verbs etc. as much as possible.
Of course, you are correct, but we don't always have the luxury of being able to hand an entire string to a localization team, and some programmatic interpretation often needs to be done.
The best way to deal with it, is to design code that allows entire sentences to be handed to translators (I do that, most of the time).
The other advantage of writing localized content, is that it can be easily modified by non-engineers, like marketing folks. Talking points and corporate glossaries are important. Even if we don't plan to localize, it doesn't hurt to use localization tokenized content.
I would gently suggest taking the spirit of our Ts and Cs into account, when critiquing others.
I was simply sharing a quick technique that may not be known by some folks (the "$" in sprintf). It can definitely have uses.
I've been writing localized software for over thirty years. I worked for a Japanese corporation that localized into more than 20 languages (including RTL and up/down). Pretty much everything I write is localized up the yin-yang. Even my test harnesses are usually localized, as I like to keep the habit of writing localized software. I've written systems that have been adopted worldwide, in many different languages, and are still in use (and expanding), many, many years later.
There's a teensy little chance that I may have something valid to contribute to the topic.
There's a teensy little chance that I may have something valid to contribute to the topic.
That may be true, but the criticism of GP still stands.
Yes, in some special situations your approach might be the only viable one (just as how in every codebase you sometimes have to cut corners), but GP is right in pointing out that this is a problematic approach, especially without qualification ("only use this if ...").
Yes, but don’t you think it might be little more diplomatic to say something like:
> While this is an interesting way to allow a translator to arrange the order of terms, there’s a great deal more involved, like … , so we should probably avoid using this technique, if at all possible. It’s always a much better idea to allow translators to work on an entire sentence or paragraph.
See? We get to show off our expertise, without throwing shade on others.
BTW: I have learned, the hard way, that cultural and human sensitivity, as well as basic respect and kindness, are important, when localizing.
But I guess those values are kinda “last century,” and don’t really have any value, in today’s hyper-competitive world.
I don't know, I personally value directness more than a "compliment sandwich". And I don't consider criticism of code to be criticism of one's person or expertise. It may be a cultural thing (I'm German).
But you'll have to take that up with the person you originally replied to.
Comments
The code example should rather be an example of what not to do. This method of concatenating different parts of sentences would fall short for any language where the adjective and noun change the form depending on each other and the context (ex. cases). Most Slavic languages make heavy use of this concept. The solution is to just have the full sentence as a single string and let the translation team write it out in its entirety. Avoid interpolating nouns, adjectives, verbs etc. as much as possible.
It was just a silly example.
Of course, you are correct, but we don't always have the luxury of being able to hand an entire string to a localization team, and some programmatic interpretation often needs to be done.
The best way to deal with it, is to design code that allows entire sentences to be handed to translators (I do that, most of the time).
The other advantage of writing localized content, is that it can be easily modified by non-engineers, like marketing folks. Talking points and corporate glossaries are important. Even if we don't plan to localize, it doesn't hurt to use localization tokenized content.
Oh, BTW. This is how not to do it:
I would gently suggest taking the spirit of our Ts and Cs into account, when critiquing others.I was simply sharing a quick technique that may not be known by some folks (the "$" in sprintf). It can definitely have uses.
I've been writing localized software for over thirty years. I worked for a Japanese corporation that localized into more than 20 languages (including RTL and up/down). Pretty much everything I write is localized up the yin-yang. Even my test harnesses are usually localized, as I like to keep the habit of writing localized software. I've written systems that have been adopted worldwide, in many different languages, and are still in use (and expanding), many, many years later.
There's a teensy little chance that I may have something valid to contribute to the topic.
That may be true, but the criticism of GP still stands.
Yes, in some special situations your approach might be the only viable one (just as how in every codebase you sometimes have to cut corners), but GP is right in pointing out that this is a problematic approach, especially without qualification ("only use this if ...").
Yes, but don’t you think it might be little more diplomatic to say something like:
> While this is an interesting way to allow a translator to arrange the order of terms, there’s a great deal more involved, like … , so we should probably avoid using this technique, if at all possible. It’s always a much better idea to allow translators to work on an entire sentence or paragraph.
See? We get to show off our expertise, without throwing shade on others.
BTW: I have learned, the hard way, that cultural and human sensitivity, as well as basic respect and kindness, are important, when localizing.
But I guess those values are kinda “last century,” and don’t really have any value, in today’s hyper-competitive world.
I don't know, I personally value directness more than a "compliment sandwich". And I don't consider criticism of code to be criticism of one's person or expertise. It may be a cultural thing (I'm German).
But you'll have to take that up with the person you originally replied to.
Just remove the first sentence of that post and it's fine. It's even in the HN guidelines: