I noticed when the manifests became empty the editor doesn’t work in Korean, Japanese, and Chinese. I replaced the manifest with the original working version and it worked.
Did you make an archive for language code “ar” that have a blank translations?
If your “ar” archive is now full of blank translations then you got it. You should be able to enter translations into those files, save them, and then run the same cmdlets again which should update the locres with your new translations.
I have empty JSON files with archive extension
Do you have a real-time chat application so we can use? like Skype?
I’m Arabian Maybe I Can Help U ! 
i’m arabian too and i’ll be pleaserd to see this project done if any way i can help just ask
I’m wondering as we now have Middle east Community
is this project alive ~?
Definitely not alive at, but you could bring it back!
Unlike when this thread was originally started, we actually have some Arabic support in the engine and will be polishing the technical requirements for Arabic off in the coming months. It would probably release with 4.12 engine release.
Now that won’t include any translations, it just means that it is now possible to realistically create an Arabic game in UE4.
Just to let you know, 4.11 will contain an early access version of our work to add right-to-left and bi-directional text support to Slate, including support for complex shaped text (such as Arabic).
Preview 1 contains a version that works with static text, and preview 2 will contain multiple fixes to allow you to edit bi-directional and right-to-left text, as well as some improvements to rich-text support.
I encourage you to check it out and provide feedback (feel free to post it here), although I’ll warn you that it might be a bit rough around the edges right now.
Known issues:
As Justin mentioned above, this doesn’t mean there’s a translation of the editor available, nor have we done any work on layout management; however it should now be possible to (mostly) make a game that uses Arabic text.
we don’t really care now about the translations much , that can be later. we have been using alpha png for the text and wasting alot of time so writing Arabic in Editor without any 3rd will be awesome
we sneaked around this part with UI
that’s great, i didn’t download 4.11 yet but after this reply i’ll definitely checking it.
as i mentioned before, most of the ME developers know English " or trying " the only problem was rendering the text only .
Thanks for including these features.
Hi!
It’s great to know that UE do support Arabic shaping right now! I have a few things to discuss about the issues 
And about the layout management, will it be possible to see a RTL mirrored layout automatically or the developer must do it by calling some functions or passing parameters?
You really did a great job! Thanks a lot!
PS: Will you accept Arabic translations for the editor? I did open this thread [1] but no one said anything about :
1: Localization of Engine and Editor - C++ - Epic Developer Community Forums
That would be the longer term plan (hopefully for 4.12). Slate supports composite fonts, however we’ve not created one of those for the core/editor style-set yet. That said, we could simply specify a fallback font for Arabic without too much trouble (this is how CJK languages work right now) - do you have any suggestions for Arabic fonts that look similar to Roboto and would blend well?
The reason that multi-line text was done first is that it was already using our text layout system (which is essential for managing complex text due to the runtime cost associated with shaping). The text layout actually powers all of our text based widgets, with the sole exception of [FONT=Courier New]SEditableText. For 4.12 I’d like to extract the implementation from [FONT=Courier New]SMultiLineEditableText and share it between the two widgets so that we’re not longer duplicating logic (however I can’t say for certain that it will happen for that version).
Bi-directional text is fully supported, and the base direction of the text is detected per-paragraph (blocks are re-ordered if required based upon this base direction). This means you can freely mix RTL and LTR text anywhere within your text.
It’s currently experimental, but you could use a 3D UMG widget as an alternative to a Text Actor. UMG is built upon Slate, so shares all of the Arabic support.
We haven’t given that much thought yet, and there’s no timeline for when the layout management features will be implemented. Currently we’d advise creating two HUD layouts yourself, one for LTR, and one for RTL (although we realise this may be difficult if your HUD/UI uses a lot of text).
Without a proper Arabic font in the Editor, we wouldn’t be able to display the text right now. Also, how strange would the editor look in Arabic without layout mirroring? Basically, we still have things that we need to address before we could translate the editor into Arabic 
Thanks! It’s been an interesting learning experience, and quite mind-breaking for someone used to dealing solely with LTR text. I just hope it all works okay
I think “Droid Arabic Naskh” is just a good Arabic font for monitors and do blend well with Roboto. It’s used in Android as the default Arabic font.
That sounds great! =)
As a starting phase, it’s just ok! Developers will be more happier if widgets got mirrored by magic, but it’s better to leave it until Arabic support is tested and fully working on all of the text components
You are right about the strange look if the layout was LTR, but I don’t see it really non-functional, as Blender do not mirror the layout although it’s translated to Arabic.
Let’s just hope that! I’ll try the First Preview version of 4.11 and see how things look like =)
That seems to work well, and we’re already using some of the Droid fonts. I’ve added a test for that in the editor (which actually found a serious bug with my block ordering!), and am currently checking with legal to make sure we can use this font. All being well, this should make it into 4.11 preview 2.
You’d currently need to change the editor language to Arabic in order to be able to draw Arabic text correctly in-editor (Note: this doesn’t actually translate anything, as we have no translations). Hopefully for 4.12 I can get a proper composite font sorted out.
Looks sweet! <3
It’s really great that such support get into the core of UE and makes translation to Arabic for game developers much more easier (Well, almost as it’s with other normal languages ).
Amiri font is great, the greatest Arabic (And other languages that share the same character login like Persian) font I"ve ever seen, but it’s just not the right font for displaying text in widgets.
I’d like to ask you about the way you are getting the translations of the editor. Is it a company you’re dealing with or you can accept something from the community? I just couldn’t find the translation files in the source code, all of what I found is file paths :
And just a question out of the topic: Did you find a way for plural handling?
Thanks again =)
We currently use OneSky to manage our UE4 translations, and we have our own translators for Chinese, Japanese, and Korean. OneSky is able to handle community translation, and I believe our Spanish and Portuguese translations came from the community. We’ve not yet decided how to handle Arabic translations for UE4, but our main concern with a community translation would likely be quality control since no-one at Epic speaks Arabic, so we have no way internally to verify that a translation is correct.
The translations for each culture are in the “UE4\Engine\Content\Localization” folder. For Arabic, each of the localisation targets in that folder would contain a sub-folder for “ar” (you may see these appear in 4.11 preview 2 as I need an Arabic “translation” of the fallback font path in order to use Droid Arabic Naskh).
If we did allow community translations of Arabic, we’d probably just set you up with OneSky access. OneSky is always treated as the “correct” version of the translations, and if you were to edit the files in “UE4\Engine\Content\Localization” they’d potentially get clobbered the next time we updated our localisations from OneSky (which happens nightly).
Not yet We’re aware this is something we’ll need, but there’s currently no plan for handling it, nor a timeline for when it will be implemented. I’d be interested to hear any thoughts or experiences on how pluralisation is usually handled though.
Oops, I forgot that you’re using OneSky! I just couldn’t find a way to reach to the UE project there. And yes it would be a hard-decision on who will handle the translation with the fact you said! :\
I really tried to find the “Content” folder in every branch but with no luck at all.
That’s very kind of you! 
And yes, working on the source code directly would result in throwing the work because of the synchronization with OneSky.
Well, there is gettext and tinygettext. They just use a single-line C function that describes the different rules for each language and select the right form according to the variable. Here is the file of plural forms in tinygettext: https://github.com/tinygettext/tinygettext/blob/master/src/plural_forms.cpp. They just compare the string found in the po file (the plurals header) with the string in the code, save it in the localization dictionary, use it whenever a plural string appeared by passing the number to it so it returns the form number (0, 1, 2…) and use the right string (Doing the actual variable replacement)
And here is a list of the plural forms used by Gettext: Plural Forms — Localization Guide 0.9.0 documentation
Hopefully you’ll find your way to get it in upcoming releases
This is fantastic news for me! I’ve been using Blui to compose my arabic text in an HTML window - and it’s a bit clunky. I’m using the engine to render graphics for an Arabic TV show and it’s been a bit painful to tell the truth - I think my solution may be a bit unstable as i’ve got 9 embedded chrome windows running at once - i’d love to put all of this stuff in the UMG. Would it be silly for me to invest time in using this in it’s current state?
Also, how does the engine deal with overrides. The classic example is the line:
We find the phrase ‘ARABIC LINE IN HERE’ 5 times in the text.
In this case - using normal BIDI in html you have to override the string with LTR/RTL markers or it puts the 5 after the word ‘phrase’ thinking the 5 belongs to the arabic rather than the english.
Thanks!
Are you dealing with mostly static (ie, non-editable) text? The system in 4.11 should be pretty solid for static text, although I myself don’t speak Arabic which is why I’m keen to get feedback on it to ensure everything is accurate.
A good question, and not something I’d previously tested. We use ICU to detect the direction of text, and by default that will do the re-ordering you mentioned, however you can use a LTR marker to override that behaviour. Note: In the current preview build of 4.11, we incorrect render a glyph for control codes… I’ve fixed that, and it will hopefully be a part of the next preview.
Here’s a screenshot showing the text with and without the LTR marker (this is from my fixed version).
The second line is the correct one -visually-, however, it’s not what my word processor says…
But I found a bug in rendering
): بديع الزمان الهمذاني - المقامة البغدادية - ويكي مصدرGood spot! I’ve fixed that too - (the text shaping library we use) gives us negative Y advance and offset values, but our Y advances positively, so we just needed to flip the sign.
This has actually highlighted an issue you might encounter due to the basic fallback font system we’re using in 4.11. It is assumed that a fallback font is no taller than our default English font (Roboto), however Droid Arabic Naskh is quite tall, so some text (such as the Kasra diacritic) may appear clipped.
This is less of an issue when using a composite font (which I hope to get working in-editor for 4.12), as you’re able to scale down sub-fonts to fit within the line height of the primary font. An alternative might be to set up an Arabic specific composite font, where an Arabic font is used as the primary font, and then other languages may be added as sub-fonts (if required).
In the screenshot below:
