So I understand how Multilingual App Toolkit 4.0 works and it works great for my Xamarin.Android project. The default language is English, and with MAT we've translated it to Dutch and German.
Then comes the translator along and asks about how to make changes to the English texts, which is my source texts and the basis of all translations. The source texts (English) are in a file Resources\values\Strings.xml. Alter a string there, would invalidate all translations (Dutch and German).
Besides invalidation, I can't send my translator the normal .xlf file, because all source texts are in the Strings.xml file.
So my question is, how can my translator alter the source language texts in the most easy way (preferably with an .xlf file)?
The short answer is that you can't. The design of the Multilingual App Toolkit focused on providing easy support for translation into other languages. The concept of providing source content editing was not considered.
That said, as a workaround you could add another variant of English. For Android apps, the default is English Neutral (en), so adding en-US or en-UK would create the XLIFF file that your translator / proofer could edit using the same tooling (e.g.: Multilingual Editor) to provide source content proofing. If using the same translator for proofing and translating, they could apply the translation based on the update English string to the Dutch and German files.
When you receive the XLF files back ensure all the resource in the proofing English XLF (e.g.: en-US) are marked as need review, translated or final (basically anything except 'New'). The reason is that the Multilingual App Toolkit does not include untranslated resource in the generated target resource file. (The reason is for language fallback purposes in Windows apps).
Now you can import the proofed English file with the other XLF file and build. Copy the entire contents from the proofed English resource file(s) overtop the original source files (recommend Comparing first). When you next build, you will receive warnings that the source resources have changed after the translation, but you can just review and clear those warning in the editor, or clear them globally within the Visual Studio IDE.
Related
When using the Multilingual App Toolkit extension (version 4) in Visual Studio (2015) is there any way to prevent one of the resource files in the project from being translated?
In the Multilingual App Toolkit I have two languages added using Add translation languages...
I've now added a new resource file resourceImages.resx to my WinForms project to contain images that should not be localized.
The toolkit has automatically created resourceImages.fr.resx and resourceImages.de.resx. Is there any way I can prevent this - I do not want the images to have translated versions and I don't want them to appear in the xlf translation files that our translators will receive.
The author of the Multilingual App Toolkit has now answered this question in the Q&A tab here
There is no option to ignore resource files with MAT. However, by default the entry in the XLF file is a reference to a image location and not the image itself. Marking the image resource(s) as Translate = 'No' in the XLF file will prevent the images references from being added to the target language image resource files. This is because resources with a Translate = 'No' are not added to the target resource file. This should allow you to use a single image for all languages without any project bloat.
Does unity support arabic writing in InputField UI or even GUI Texts ?
I mean if I want to write arabic characters in the InputField, does unity support that ?
There's a free library for supporting Arabic language in Unity. You can download it here
This is part of the readme file. Just add the library and use one of GUIText or 3DText prefabs.
To use the Unity Arabic Support asset inside a script, use: using ArabicSupport;
After using the using statement, use the following method (returns a string): ArabicFixer.Fix(textToBeFixed);
And you're done! You can use the alternative: ArabicFixer(string, tashkeel, hindoNumbers) for more customization options.
No by default but there are libraries/asset packs to make it work.
Just search "Arabic" in the unity store to find them.
Keep in mind that it is really hard to setup TextMeshPro (The addon pretty much everyone uses for crisp text in unity) in Arabic with a different font as most Arabic fonts you find will not have all the characters you need.
Lookup this to see the encoding range you need to put in the font asset creator.
For example you will be able to write letters but only some of the letters will be connected as the font does not have all possible connections and unity wont make them by default.
But I think the Adobe Arabic has all the letters for a start.
It should if you save the script with UTF-8 encoding. Then you should be able to include all unicode characters in there.
short answer : unity doesn't support Arabic or Persian although
there are bunch of plugins on assets store that can buy you some times.
you can find them easily.
I have created a Firefox Add-on using jpm and I have added a number of localization files such as:
locale/da.properties
locale/en-GB.properties
locale/en-US.properties
locale/fi.properties
And so on...
In my HTML files I use attributes to set these values, for example: data-l10n-id="ext_panel_heading_text".
I know the translations are working, because changes I make to values in en-GB.properties are reflected in my add-ons HTML page.
I've tried navigating to Options > Content > Choose... (under languages), removing English and adding another language (such as Finnish), however it doesn't seem to have an affect on the .properties file loaded by my extension. I also tried restarting Firefox after changing the language.
My question is: How do I test the different languages?
The language of Firefox is dependent on the activated language pack, or for Windows and Mac I believe it is hard coded into the build.
Language packs are available from https://addons.mozilla.org/en-US/firefox/language-tools/
The only way I know is to change general.useragent.locale to the locale you want to use (en-GB, da, en-US, fi) in about:configand then restarting your browser: that way your add-on should show localized texts.
As an alternative, you can use Quick Locale Switcher, which does the same but it's a little more friendly.
This is ideally what I'd like to do:
Set up a project in Xcode using a base localization of English. Ultimately I want English and let's say Dutch versions of my Localizable.strings and Storyboards
Externalise strings in code with NSLocalizedString, using keys of the form fooViewController.barLabel, being diligent and adding proper context comments with every key
Add a Dutch localization to my Storyboard files
Mark particular labels in the Storyboard as placeholders that will be set at runtime and do not require translations
Add comments for labels in the Storyboard which do require translation
Export the "development language" xliff file (Click on Project, Editor/Export For Localization..., choose "Development Language Only")
Open the English xliff file in a tool like Counterparts or Xliffie or even something web based
Add actual English translations alongside the fooViewController.barLabel keys, and re-save the en.xliff
Create an nl.xliff file from the original en.xliff and add Dutch translations
Import both xliff files into Xcode and have it create the appropriate .strings files for both Dutch and English, for both the keys defined in code and those in the Storyboard; commit the new .strings files into my source repository
At some future point after keys have been added, removed and changed in my source and Storyboards, export the "Development language" en.xliff again as the source of truth
Update the en.xliff and nl.xliff files with current translations, having a tool highlight which keys had been added or removed
Import those xliff files back into Xcode which updates the .strings files I can then check back in to my source repository
Does this make sense? Is this a reasonable thing to want to do? I think so, but it doesn't work.
Here are the problems I ran into:
Xcode does not support step 4—the xliff format can mark a key as translate=no, but there is no way to annotate that in Xcode (ideally, Xcode wouldn't export keys marked as placeholders at all.)
Xcode does not support step 5—there is no way to set a translator comment for a label. There's not even a way to set the key independent of the placeholder text you put in the label on the Storyboard, which is a massive pain if you find filling labels with Lorem Ipsum useful when laying out your views.
When you get to step 10, Xcode complains there is no target language specified in the en.xliff file. There is a way to change the target language (or, at least, create a new file with the target language set to EN) in Counterparts but I couldn't find any way to do this with Xliffie.
Upon attempting to re-export the en.xliff file with updated keys, Xcode told me "Localization failed reading "[...]/Supporting Files/en.lproj/Localizable.strings, Please address the issue at file location 782" at which character location I found... an apostrophe. Xcode can't export an xliff file if the source .strings file contains an apostrophe. What in the actual F...?!
Step 12 and 13 got weird, and I just don't understand what was happening. Both Counterparts and Xliffie had replaced my original fooViewController.barLabel keys with the English translations and looked like they were trying to tell me I had no English translations. Upon attempting to import the en.xliff back into Xcode it told me I had no translations for all but the new keys and when I went ahead, it wiped the existing translations from the en.lproj/Localization.strings file.
This is a mess.
Translating labels in Storyboards without being able to manually set their keys, add translator comments or mark particular labels as placeholders not-for-translation just doesn't work. We've resorted to connecting every label to an #IBOutlet and setting its translation in viewDidLoad() with NSLocalizedString.
Xcode choking when it attempts to export a .strings file containing an apostrophe beggars belief.
It also seems there's an underlying assumption that if the "development language" in Xcode is English, then the developers are in charge of the English translation. I can imagine no context outside that of a single-person indie developer shop where this is true.
Finally, it also seems I'm missing something about how the tools I've attempted to use structure their workflows. If anyone could enlighten me I'd be quite grateful.
Has anyone managed to construct a workable localization workflow where the developers aren't charged with ultimate editing control over the "development language" and the .strings files checked into the repository are the source of truth?
We've resorted to connecting every label to an #IBOutlet and setting its translation in viewDidLoad() with NSLocalizedString.
You are doing that right. Seriously. Wrap your development process around it and you'll get way better off than trying to adopt the mess that the Storyboard localization evolved into.
It solves pt.4 - you decide what you put in the Localizable.strings
It solves pt.5 - comments are there by default, for everything that you decide to be localizable. Now to be honest, XCode7 has added a possibility to add notes to resources. Don't use it. For some reason only known to Apple, it is not available for all types of resources. You can't annotate e.g. table headers and footers. More on that later.
I recommend making your own NSBundle.localizedStringForKey wrapper (macro) which provides the value. NSLocalizedString sets value to empty string, essentially forcing key to be used as the fallback translation content. Of all the already existing questionable macros, NSLocalizedStringWithDefaultValue takes the value but also all other 4 required parameters - not something you would like to use often.
Step 10 is caused by you trying to import a Base localization - the fact that it's english does not make any difference. If you want to "translate english" (i.e. professional correcture), you must add english as another standalone localization on top of Base. Technically it boils down to the Base xliff missing <file target-language> and <target xml:lang> properties. Due to some strange xliff mess similar to yours, i had to add those once manually. You don't want to do that :)
Re apostrophe glitch: iOS localization is an unreal garden of wonders, but i'm prety sure it's not THAT unreal :) Try opening the file in some hexcode displaying editor - what XCode renders may be quite different from what the file really contains.
... even something web based
That's Crowdin for us and it nicely shows everything wrong with Apple's idea of Storyboard localization. Translators need 3 things to do their work professionally: context, context and context. Apple seems to think that translators will gladly install the app, play with it and ask questions to get the context. Because, by default, there is no human context in xliff export. Now with Xcode7, you can add notes, but weirdly not everywhere. Even where you can, your note is appended at the end of already long <note> string with machine context - understandably needed for storyboard import matching, but useless and obstructive for the translator. Furthermore, in reality, the translator is a pro agency, or a language enthusiast. Even if you had a luck with properly equipped enthusiast, or you paid the agency premium for getting an extra customer care, you enter The Hostile Desert Of Beta Distribution Options. Apple's funny Testflight reincarnation will either need the translator to register as an Apple developer, or waiting for Apple's beta review - depending on how early in the app life you need the translation.
BTW i like your blog. Sometimes i feel like dumping my sourness and misfeature fatigue too, but never got as far as you :)
I'm trying out FTGLES to dynamically display text in arbitrary fonts on OpenGL-ES on iOS (cf. my SO question here). That library seems to require direct access to the TTF file to use the font. Using kosher methods, can one directly access -- by path -- the system font files on iOS? I've RTFM'd and couldn't find anything.
Barring that, does anyone know if it is Apple-approved to copy the system fonts into your app (before submission).
My solution was inspired by skia.
Though cannot access system built-in font files directly, we still have an indirect way:
Create a CGFont with your wanted font name, all contents of SFNT table of this CGFont can be accessed by simply calling CGFontCopyTableTags() and CGFontCopyTableForTag().
A ttf/otf font data can then be constructed by using these tables, save the new created font to disk, you can use it in FTGL ES later.
No, you can't access the system installed TTF files on iOS devices. So you'll have to embed the typefaces you'd like to use.
Disclaimer: I'm not a lawyer, and the acceptability of using Apple supplied system fonts in an iOS app is a legal question about interpreting software licenses, so you may want to seek professional advice.
You wish to embed an Apple supplied font in your app. The definition of "embed" is a bit nebulous, so adding the font to an iOS app may or may not fit within the copyright holder's definition of "embed". Some type houses define "embed" to mean just viewing predetermined content in the included font; other mean viewing and editing content in that font. Displaying content that changes during the running of your app is somewhere between these two cases.
According to the Mac OS X Lion 10.7.2 ELUA:
F. Fonts. Subject to the terms and conditions of this License, you may
use the fonts included with the Apple Software to display and print
content while running the Apple Software; however, you may only embed
fonts in content if that is permitted by the embedding restrictions
accompanying the font in question. These embedding restrictions can be
found in the Font Book/Preview/Show Font Info panel.
If using the fonts in an iOS app is indeed "embedding", you just need to check the particular fonts you wish to use in Font Book.
In this situation I would find a font or set of fonts where I had explicit permission to include the fonts in the iOS app. I would start by shopping around the various type houses for a licensing scheme that explicitly allowed this use. This may get expensive, so another tack would be to seek out open source typefaces with a license that would allow this use. Or, for a very limited set of characters (e.g. only numbers) I would even consider drawing my own typeface.
No. Your app cannot access files outside the sandbox of your app. Period (well, unless it's jailbroken ;). But you can indeed bundle the font file. Now, I see no reason why Apple would reject your app, as it's using a file already available on the device, and you're just including your local file to it. In terms of copyright, Apple already has that permission to use it on their device, so your inclusion of it should be no problem.
I say should because I haven't needed this capability and haven't tested it with a submission of my own, but based on legal instinct and font copyright issues I've seen in the past, I'd expect that it wouldn't be a problem.