Fix DOpus localization capabilities

Xyzzy · February 4, 2024, 12:39pm

There are still major problems with DOpus localization capabilites - will they be fixed at last? Like, they are there from day one - almost two decades already...

Combining segments

Never, EVER split a single statement into recombinable segments. "There are files to delete" and "There are folders to delete" and "There are directories to delete" should be complete, SEPARATE segments. Passolo makes it trivial to reuse similar segments. Segment combining makes translation harder and more error prone.
Obviously, placeholders for EXTERNAL LITERAL TEXT (quotes - NOT parts of statement) are perfectly OK. "Delete column %s?" (column name for %s) or "You have selected %s to add files to" (collection name for %s) or "Message '%s' will be displayed" (message text for %s).

Reusing segments

Never, EVER reuse segments in different contexts. If you have fe. two drop downs with "Size" in them, make it TWO SEPARATE SEGMENTS. If you have "Size" text in 20 places, CREATE 20 SEGMENTS to translate. Passolo makes it one click operation to reapply given translation to all the places where it occurs, if needed. The CSV file you provide gives context for each segment. Otherwise you have strings which are incorrect in translation in half the places they appear.

Lack of proper numeral handling.

Lack or flexible numeral handling causes that in any language more complicated than English there are very often two solutions - create translation which is (very) illegible or linguistically incorrect. There is a whole Unicode ICU standard to solve this problem (Formatting Messages | ICU Documentation, JS interpretation: Message Syntax | Format.JS), but anything is better that the current state of neglect.

Using MT

Don't use machine translation for ANYTHING. Really. It is engine for introducing difficult to spot errors in bigger segments and producing trash for short segments (like UI). Not once I have discovered such crap introduced into translation in this way, not to mention the effort to correct it and then again correct what has slipped through.

Leo · February 4, 2024, 12:41pm

We aren’t going to rewrite the whole program to enable perfect Polish grammar beyond what any other software for Windows including the operating system itself does, no.

If there are strings that are used in multiple contexts that need splitting up, we can do that. Just tell us which strings are causing problems and we can split them.

Xyzzy · February 5, 2024, 5:57pm

Is DO really so badly written that you would need a complete rewrite to enable decent l18n?

Not perfect, just correct, legible and readable.

Rest assure, the issues are with each and every translation langauge. With some bigger, with some smaller.

In any Microsoft software not adhering to 1 and 2 is a product bug. It is raised and fixed without discussions. Many commerce products (and Office maybe? - I don't have it to check now) adhere to 3. But, why race to the bottom?

Strange, pixel/color fetishists have their release now, and folks just wanting to be able to read program texts comfortably are ignored.

You don't have any serious experience with software localization, do you?

MarkusN · February 5, 2024, 10:57pm

I can confirm the problems with the translation of DOpus. Anyone who has never translated a software into another languages will find it difficult or impossible to understand the problems.

You spend a lot of time finding out where a specific text segment is used and then have to make corrections across several translation versions. This even applies to individual terms where it is unclear where they are used. Is it a verb or a noun? Is it singular or plural?

The next difficulty is the length of the texts, as almost all languages become significantly longer than the English text when translated. Fortunately, this has been resolved in most places in the new interface and words that previously had to be shortened beyond recognition can now be written out again.

I have already translated many software products. None of them were really well done, so I don't know of a good example. I have been dealing with the problems of translating DOpus for many years and see it as a challenge to still deliver a good translation. However, I have the advantage of having a very accurate tester and a few other users who point out any errors to me. Without this help, the translation would not be as good as it is and there is still work to be done...

Leo · February 5, 2024, 11:16pm

We have the slack channel now where queries about how strings are used can be answered very quickly.

What Xyzzy has been asking for is a way for translations to include script code which can modify strings and word choices/orders, and even move UI elements around. That's beyond anything I've seen in Windows software, beyond the dialog/string resource system Microsoft have defined as the standard, and beyond what Windows itself does.

It would be years of work to make the UI able to do that, and would massively complicate the translation process for all languages and translators. That effort simply doesn't make sense vs other work we could be doing, especially given the small number of people using Opus in affected languages, and that anyone using those languages will be used to slightly awkward sentence constructions from almost every other piece of software they use and the OS itself.

Also, any time that was brought up with the other translators, they didn't express any interest in it.

Xyzzy · February 6, 2024, 7:52pm

OK, so before going to technical stuff, let me explain - why (without even touching customers' reception).

You obtain free labor worth thousands of dollars, which surely brings you some extra sale. (The prices vary wildly depending on what/whose pricelist you take, but this is very, very modest assessment). It would be honest and decent to make this work as easy and meaningful as possible. Yes, we get a gratuitous copy; considering the amount work we do, it's more like "Thank you" (which I appreciate and which is generally accepted practice).

I don't know also what kind of translators' feedback you still need after all these years to push this matter forward. Would 3 posts from each on the forums with big red letters would be OK? What do you expect from ten people to raise attention - repeating the same ad nauseam? Besides, needing to justify good development practices to a programmer seems... awkward.

Still, all the translation effort on your side must manageable. So let me "explain how".

First, I completely have no idea where you've got the impression that there is anything to do with controls manipulation of any kind (moving, sizing, coloring, text styling, whatever). Everything applies to pure text only. Also, I've always done control corrections (size, arrangement) in Passolo myself, with Greg handling only some odd cases.

Regarding "points 1 and 2" - keeping from combining and reusing segments - there is nothing you technically need to do differently than you do now, I think it's obvious (and IMO it would be easier also for you). I can send feedback for these, but if it's not addressed, and it's not been great for the previous ~20 years, it's just wasting my time. I sent feedback in the past, but seeing how it goes, I cared less and less with time. I think I did't bother already at all during DO 13 translation.

Regarding point 3 - you already have the engine to make it happen - Evaluator (yay, status bars can look both correct and natural now!). How it possibly could be used to feed text to controls - I have no idea. I even don't know if it would be the best choice. But at least you have an idea. Lot's of software uses ICU (https://icu.unicode.org/#h.f9qwubthqabj), and for example free program MusicBee makes it possible to decline phrases containing numerals using own simple approach. What approaches have been considered and dropped, so that this task seems unwieldly to you?

Point 3.5 which I forgot in the original post - don't create huge, half-kilobyte segments which, even worse, have a lot of repeating, context idependent contents. They are a chore to work with. Totally a middle finger.

And point 4 - Google MT - just don't, unless translator is not responding or opts-in. Or at least send them for validation. Or if you don't have time, keep a list of strings so that they can be reviewed by a translator at the nearest occassion. Even specialized Microsoft/IBM MT engines suck big time with UIs.

Also, believe me, meeting these requirements would make our work EASIER, not more complicated. That is why these directives have bee created.Even if someone does not realize it.

You say not much people use localized versions (how do you know BTW?) - and how much cares about coloring of left margin of some dropdown in "active but not focused" state?

And a cherry on the top - all what is wrong with localization in one picture - combining, reusing and phrases which cannot be declined (deletion confirmation dialog):

Jon · February 4, 2025, 6:44am

Picking this up again, in 13.13.1 we've added a way to use the evaluator to generate text messages for languages with complex rules.

At the moment the "delete confirmation" message is the only one that uses it, but it will now be quite easy to add any others you identify as needing this ability.

Feel free to ask on the Slack channel if you need help working out what the evaluator code needs to do.