I'm getting english frases like "done" and "continue" in CN1's built in components.
How may I force those labels to change to spanish? I mean, even if the phone is in english.
Thanks!
Check out this video: https://www.codenameone.com/how-do-i---localizetranslate-my-application-apply-i18nl10n-internationalizationlocalization-to-my-app.html
You would need to define a resource bundle that includes the Strings "Done" and "Continue" within it and map them to your language. Then install that bundle in the UIManager.
Related
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 :)
Is it possible to add one or more separators to the function popup in TextMate 2? Some context may help understand what I mean:
I'd like to group the functions into logical sections, similar to what Xcode does with the '#pragma -' option. Is this possible?
Thanks!
Just tested with TextMate version 2.0-alpha.9479 and
#pragma mark -
worked fine in a .cpp file.
It's a per-bundle trick and the Javascript bundle doesn't have it.
You can do it yourself by customizing the bundle to recognize some specially formatted comments for instance.
I'm using Marmalade to develop iOS applications via VisualStudio and a PC. The integration of a social feature like HeyZap needs its initialization by the use of:
loadHeyzap("YOUR_APP_ID_HERE","YOUR_APP_URL_HERE", true);
App_ID is the ID as defined in the itunes app page (I got it).
App_URL "should also similarly be replaced with your URL scheme for the iPhone" [from the HeyZap integration doc].
Well, the HeyZap help desk weren't useful to obtain this string via the use of VisualStudio+PC (in fact, they told me "use XCode+Mac instead...").
Since this is a simple string, I suppose I could obtain it starting from known parameters of my app. I suppose to find inside it something like [app_name]&=other-chars-....
Is there a way to build this string without the use of XCode, just starting from info I already have and putting here and there some special chars?
In other words, is there a standard way to automate the build of this string without the neeed to do it via XCode? I wonder to prepare a function in which I would pass my app parameters and I got the URL Scheme string as a result.
Cheers,
Zapp
The answer by Creator is incorrect. A URL schema is how apps can communicate with each other in iOS.
Here is what Apple has to say
http://developer.apple.com/library/ios/#featuredarticles/iPhoneURLScheme_Reference/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007899
An example would be:
yourgame://
Here's how you would define one in XCode
When you define a URL schema in XCode, you can call that URL from Safari or any app installed on the device and it will switch to your game.
The way you define it in XCode is by going to your project settings, clicking the Info tab at the top, going to the bottom where it says "URL Types", expand that, and click the + button at the bottom. Then define both the identifier and the URL schemes with something reasonably unique like "yourgamename". Done!
http://i.stack.imgur.com/pxEKd.png
URL scheme is most probably the url of your app in App Store. You can obtain it from iTunesConnect. Go to your application and copy the url of View in App Store link. That's the string you wanted ;-)
Let me know if it doesn't work.
Edit:
Well App url worked for me, dunno why its not working for you. If you want to edit the URL scheme, you can do it without using XCode too. You need to include Info.plist file in the mkb settings. You can edit or check the current URL scheme being used by marmalade there. The default plist file is in the s3e folder. Don't know the exact location.
I want to know where I can get access to the NinePatch images specifically for Monodroid. I want to change the default coloring from blue to orange (if I was doing this in Java it would already be orange).
All I need is to change an edittext so that it's default colors are different. I have seen
http://www.androidworks.com/changing-the-android-edittext-ui-widget
which is really helpful but only as far as vanilla Android is concerned. I tried following the instructions, but I found the standard orange java images, not the Mono ones, which are blue.
Minimum framework is 2.2. I know that I am getting the java images because when I go to C:\Android\android-sdk\platforms there is no android-2.2 folder.
I'm not really sure what you are referring to. Mono for Android does not ship any NinePatch images. Mono for Android simply provides a thin binding over the Java API, it does not do anything custom.
Maybe it is triggered by changing your Android target framework?
I found my answer - and thank goodnesss it did not involve changing the 9Patches!
You can make an xml in the drawable folder which describes your button, textbox, etc. and make a selector with a solid tag, pressed event, etc. (http://developer.android.com/guide/topics/resources/drawable-resource.html)
Then you can set up the colors as a constant set in the Values folder and boom! Solution!