jockeril wrote:
I appreciate your explanation but all it's done, since I'm not a programmer, is confuse me about the difference between "logical" and "visual" representation of the text, and again - using scripts is not something I can do.
I hope the #dev team will sometime soon allocate the resources needed to make the changes so I don't have to continue translating & inverting the locale files text for the game.
FYI (1) - it turned out to not just be a matter of inverting text but also adjusting some of the original translation and the combination of hebrew & English in a sentence to appear correctly on screen. This is the reason it's not finished yet.
FYI (2) - Trying to use GitHub to publicly deliver the mod to the masses

, I'm having problems uploading my local files to the repository... still learning how to work with that
Ooops, I guess I assumed every right-to-left "speaking" person who ran into RTL problems will know.
In retrostpect, how silly of me.
I wrote this wall of text to explain, so I won't be offended if you read a wikipedia article instead.
Let me explain the unicode ordering methods.
You probably know, that a file in a computer is a series of bytes, usually read from the beginning to the end.
The same goes for text strings, they are represented by a series of bytes.
In the early days it would be too costy to support both text directions at once,
Those are the days of ASCII (and its upper-half extensions), where one byte equaled one character
and those were printed left-to-right onto the screen as they were read from the file/source.
All/most of? text drawing code did that. But then someone needed to diplay something Right-to-Left.
But the code was drawing characters from left-to-right as they arrived on the input.
Heck, there were some "electronic typerwriters", that wouldn't even technically be able to print in the other direction.
The obvious workaround to that problem is what you're doing now. That became known as "visual ordering".
In that the first data byte of a text string is the
last character of the right-to-left text.
When the program then draws the string, then it reads this first data byte and puts it at the leftmost position.
That worked. Had it's flaws - the text printed this way would be obviously left-aligned and look odd I guess.
The point of "visual ordering" thus is, that it requires no program change to display seemingly R-t-L text.
You just "change the font" and invert the order of characters in the string so the code encounters them in right L-t-R order.
Even thought it looked (mostly) right, it sure had a lot of limitations.
For example text-processing tools (seeing the data bytes) had now no clue where the text should be appended.
If you would be to write a long text file in R-t-L (assuming no newlines), the file to store it would
kinda have to be written from the end to the beginning to create a logical ordering. And implementing "end-to-start" filesystems proved to be too complicated or too awkward I guess. Even more awkward for mixed text OFC.
Then, the "logical" ordering was conceived.
In logical ordering the first data byte of a text string is the
special LTR character, which merely notes,
that the following data bytes should actually be printed from Right-to-Left.
If the program drawing such text doesn't support that, the text will appear to be drawn in reverse order.
However, it does solve the storage issue very nicely. Now both LTR and RTL text files can be amended by simply appending bytes.
I'm suspect that talented programmers did something to display text "right" in your region in the early days, but no idea.
Glossary:
"visual ordering"
- text data bytes contain the leftmost="
last" RTL text character first.
- Compatible with old code but awkward to edit or text-process.
"logical ordering
- text data bytes start with "RTL" character, then follows the first-char-to-be-read-by-human=
first RTL text character.
- This needs the code to understand RTL and be able to draw in RTL direction. Editing works nicely. Preferred.
"RTL" - Right-to-Left unicode marker - data bytes read after this one are printed from the right
"LTR" - Left-to-Right unicode marker - data bytes read after this one are printed from the left.
Does my former message make sense now?
What you do now: in-cfg-file: "visual", in-game-data: "visual"
Fix that I propose: in-cfg-file: "logical", in-game-data: "visual" (automatic conversion while adding translations to game)
Once the game gains support for drawing the proper "logical" format by itself, the conversion will simply be removed.