-
-
Notifications
You must be signed in to change notification settings - Fork 957
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #6666: brackets in arabic strings #7480
Conversation
STR_SORT_BY_ENGINE_ID and STR_STATION_LIST_SELECT_ALL_TYPES both have mismatched parenthesis as well. |
I've made myself a list of strings which maybe have this error aswell.
|
Instead of {BLACK} there should be one of the RTL-codes, see: strgen_tables.h#L146 |
If I use the following, the problem is still there.
Using |
I'm not sure you're really doing the right thing here. LRE marks the whole string as being left-to-right (until a PDF at least), and that doesn't sound right. Doing a back-and-forth Google Translate round leads me to this bracketing:
OpenTTD (on Windows using Uniscribe) displays it properly. |
Well, we want the whole string to be left to right, otherwise the bracket will jump to the end of the string. Or am I wrong there? Within VS, the bracket, if you type it at the front of the string, will jump to the back. Probably the same what seems to occur with Google translate. Tomorrow I sure can test what difference it makes using a different char or ending the left-to-right after the bracket closes (Or if anyone wants to do that now, sure, I am not on my PC anymore). |
Pre-script: My previous comment had missing - and +. The second string line is the line I meant. Please note the direction of the bracket. If I paste the string into Google Translate, it is rendered as I would expect it to render (with proper brackets). See https://translate.google.com/#view=home&op=translate&sl=ar&tl=en&text=نوع%20المحرك%20(قياسي) OpenTTD will render it the same as Google, even if the string is displayed differently in the language file. In general, declaring a string that is in a right-to-left language as has having a base direction of left-to-right seems wrong and would probably fail if the string is included in another string or mixed with LTR content. Unfortunately, I can't read arabic, so take anything with a grain of salt. If something looks right to me, a native speaker might still think it a total abomination. |
Yeah, and copying the arabic text and pasting in in Visual Studio into the lang .txt results in the formatting in my previous comment. I.e. Visual Studio (and maybe/likely the WebTranslator as well) display the string differently to how it is display in game or with a proper renderer like in Google Translate. Which of course makes the translator's job harder than it should be. |
If there's something like |
The following diff makes the string show properly on Windows/Uniscribe: |
Okay, to get the town directory to render properly in OSX, some control codes are required:
|
Ok, I'd assume that's the same for Linux then, or are there differences there too? |
@frosch123 had on IRC:
A {RLM} more for the city string, which doesn't harm on OSX. I'd hope the {RLE} don't harm on Linux , but didn't test this. Combined result:
Additionally, there's probably also a patch needed for ICU. Line 211 in 3b4f224
From IRC: The |
I pushed two commits to your PR containing the string changes and the suggested change in gfx_layout.cpp. This is not directly for using. You should squash the lang fixes and it conflicts with the latest trunk change regarding NULL and nullptr. |
On linux with icu: |
This pull request has been automatically marked as stale because it has not had any activity in the last month. |
No description provided.