Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[split] language translations concatenation issues
#1
Hi, I'm not sure if GetSimple CMS translation is still active, just wanted to chip on on something I noticed when translating my own backend.

And I want to note that I like how GetSimple is turning out. It really is simple and I very much like this software. That is the only reason I'm posting here. Please forgive me if my post feel like a rant; I do not intent it to be.


I used the Translate plugin and I'd say that it is quite a nice way to make it easy to translate. I myself didn't want to spend time digging around and learning github. (If there's a guide I'd try.) I do see the value in managing the translations using github, though.

The Translate plugin provides a better workflow than editing a PHP file. The worst thing about translating PHP files is that we spend more time moving the cursor than actually translating. With the Translate plugin, I translate, Tab, then translate the next string. For translators who often translate as fast as we type, this is extremely helpful. It's probably comparable to the benefits of auto-indent plus syntax highlighting combined, when a programmer writes code.

Now regarding the strings in GetSimple CMS. I noticed that it concatenate strings.

This is what I consider the bane of software localization. I work in English-Chinese software localization and often run into hard-coded strings like this. In GetSimple, for example, page management has a TOTAL_PAGES string that is appended onto the actual total to form "10 total pages". Because it is hard coded, the Chinese translation has to do away with the meaning of "total" and just literally translate it as "pages" instead. (The natural translation for it should be "共 10 頁".) The problem here is that the code forces word order upon the strings, and that interferes with translation. (This is also why almost all open source translated software in Chinese have weird or unnatural translations.)

In the ideal world, all variables should be represented by placeholders so order can be freely changed, i.e. exactly how the date format strings are handled. This is the standard treatment for commercial handling through software like Trados. (Although I must admit even big names like Valve, Microsoft, Adobe, etc make this mistake all the time. Especially Valve was very bad at this, it was a pain to translate anything of theirs a few years back.)

But this presents another pitfall, and many companies fall into this second trap of writing strings like "posted by %s, %s" to form "posted by zfz, 5 minutes ago". This is more or less the same as concatenating ("posted by", $author, ", ", $time, " ago"), it's not really a placeholder if we can't switch their order around.

Removing this hard-coding also means that translations won't get reverted to funny stuff just because a new translator comes on board and start to edit stuff out of context into the "correct translations". I've had client reviewers do that, then push their "correct" version into production, then get laughed at by their customers.

Another example is the tooltip also in page management: "View Page: page-title". The colon is hard coded and that forces the translation to use "English punctuation". We use full-width colons.

Lastly, style matters. In Chinese, we simply don't use italics. Yes you see it all the time, but that is very bad practice that resulted from lack of alternatives. The concept of italics in Chinese requires a change of the script (font) itself. Most fonts just look bad, and especially the standard UI/web serif font becomes very hard to read at the standard sizes if you italicize it.

In fact, the GetSimple admin back-end is very difficult to read in traditional Chinese, many italic strings are virtually illegible. This is not entirely the fault of italics, though; Chinese characters simply are not suited to using the commonly seen small size that modern websites love to use.

A properly localized piece of software will need to have an accompanying style that fits the text. But of course this is easily taken care of by providing a CJK-friendly CSS as a plug-in. This has the additional benefit that we could adjust the layouts to cater for slightly longer strings in certain places like table headings.

It would be great if GetSimple could at least remove all hard-coding from its strings. There's nothing worse than having to translate half a string; it goes beyond having to guess the meaning: it makes for bad translations.
Reply


Messages In This Thread
[split] language translations concatenation issues - by zfz - 2014-02-12, 07:41:12
RE: Crowdsourcing language translations - by zfz - 2014-02-12, 09:03:40
RE: Crowdsourcing language translations - by zfz - 2014-02-15, 13:49:30



Users browsing this thread: 1 Guest(s)