I'd like to essentially create a uilabel with chinese on it. Do I need a unicode font for this, and is there a system font I can use on the iPad? Assuming so, would I need to look up the escape character to denote it if I wanted to simply hardcode it, ie use the \u type of notation? Please assume I'm pretty clueless about unicode, as this question probably implies.
For a global product/system like this, unicode support is a very basic requirement. iOS device support it natively, including unicode fonts and codepages. No extra effort on this is needed.
For unicode string literals used in source files(I assume XCode here also), I haven't try yet, but my coworkers seems have no problem with it.
Some google results on this you can refer:
http://www.cocoabuilder.com/archive/cocoa/97208-cant-use-utf-8-source-files-false-string-interpretation.html
http://www.cocoabuilder.com/archive/cocoa/224023-unicode-in-constant-nsstrings.html
Related
Before we start, I'd like to clarify...
This question isn't about how to include emoji on labels. I'm aware that has been asked and answered before. I am able to get the emoji on the label just fine.
This question isn't about whether we can/should include emoji on labels. I am aware of the issues around that too. We'll discuss as a team whether we want to proceed with emoji, but it doesn't make me any less curious about the issue below.
With the disclaimers out of the way, our situation is as follows: We have an iOS app that deploys back to iOS 12. In it, we'd like to include the warning sign on a UILabel to signal certain situations. The text of the label comes from this bit of code (including picture, because pasting emoji doesn't come through):
This line isn't setting someLabel.text directly but it's the relevant bit. I can promise you that surrounding code simply prepends this snippet to other text and slaps it onto a label.
The first character of that literal string at the end of the line is the "warning sign" emoji inserted into the source code via hitting Ctrl+Cmd+Space and choosing it from the resulting picker. Then we have the unicode code point \u26A0.
I get the following when this code runs:
At this point I'm really curious about...
What changed between iOS 12.4 and 13.7 such that the same source code produces different output? Was the different treatment of unicode code points announced somewhere on some release notes?
Is one side somehow "more correct"? Does the "yellow-triangle-with-black-exclamation-in-it" symbol and \u26A0 technically represent different things, iOS 12 mistakenly visualized them as the same, and iOS 13 fixed that issue? Or vice versa; they are actually meant to represent the same thing, iOS 12 did so, and iOS 13 broke something? Or does the concept of correctness not even apply, since they are different representations?
Is there any code point I can type into my source file (e.g. \u<something>) that will render as the yellow-triangle-with-black-exclamation-in-it emoji consistently on iOS 12 and later? If so, what is it? If not, is using the actual emoji in my source code the only way to achieve this?
There are two variants, 26a0fe0f and 26a0fe0e. The former is the emoji variant; the latter is the text variant. In iOS 13 you are using both of them. I don't know why it chooses the second one as a fallback in iOS 13 but the first one as a fallback in iOS 12; the iOS 13 behavior seems more correct to me.
I think I figured it out, but leaving question and answer up in case it helps others.
The crux of the issue is that the "yellow-triangle-with-black-exclamation-in-it" symbol and the "black-bordered-triangle-with-black-exclamation" symbols are not the same entity. We see these in the character viewer built into macOS:
And sure enough, the representation \u26A0\uFE0F renders as "yellow-triangle-with-black-exclamation-in-it" on both iOS versions:
If \u26A0 wasn't supposed to be the "yellow-triangle-with-black-exclamation-in-it" emoji, I still can't explain why it renders as such on iOS 12...
Credit actually belongs to user matt. He had a comment which hinted at these being different, which led me down this path. The comment is no longer there for some reason (got deleted?) so I don't know how to properly attribute.
I am currently developing an iOS app that works a lot with musical symbols. the symbols I would like to use are found on this page:
http://unicode-table.com/en/blocks/musical-symbols/
I am trying out a few examples like assigning the text directly to the label. So this is what I see in Xcode's interface builder:
And this is what I see in the simulator:
I also tried assigning it programatically (Swift code):
label.text = "\u{1D15D}"
But no luck that way either. However, if I send this to the console with println() the note character is correctly printed in the console.
Just in case I tried with a few system fonts and the result was the same (Default, Arial, Verdana and Times New Roman)
So my question/questions would be: Am I doing something wrong? Are these characters not supported by iOS' interface elements like UILabels? Or maybe the problem is in the font?
I would appreciate some help here :) let me know if you need more information than what I provided here.
This is a problem with the font. Very few fonts contain the musical symbols of Unicode. The “UFO” symbols that you see are probably generic symbols for “strange” characters not present in the font. You may need to find a suitable free font and try to bundle it with your application.
A few fonts contain at least some of the musical symbols. The most commonly known of them, FreeSerif, Quivira, and Symbola are listed (with samples) at the Fileformat.info site on page MUSICAL SYMBOL WHOLE NOTE (U+1D15D) Font Support. There is also the Musica font downloadable from the page Unicode Fonts for Ancient Scripts. (The common musical symbols aren’t that ancient, but the font contains also Byzantine musical symbols.)
What are pros and cons of using Xcode base internationalization?
Maybe it's easier to use just NSLocalizedString and set titles, labels, buttons in code?
Base internalization is a much better idea than manually setting things in code. It is much less work both to implement originally and to maintain. You just add the .strings file for a language and then edit it to translate all the strings in your UI. With NSLocalizedString you have to do this as well, but in addition you need to write special code for every UI element with a string. If you add or remove a UI element, you need to write code again. Using NSLocalizedString is probably also less efficient at run time. Your app has to completely load the UI for your development language and then go through and change all the strings in the UI to the localized versions.
There really are not any cons to using base internalization except for legacy considerations:
It requires iOS 6 or Mac OS X 10.8 or newer.
Converting a legacy project with separate .xib or storyboard files for every language can be a pain since you need to convert to auto layout. (The string extraction can be done automatically by Xcode.)
Is there a font that supports all scripts? Ideally and "Apple" font, so I can use it in my iOS app without having to pay royalties.
I will use it in a UILabel.
Thanks,
Pieter
To my knowledge, iOS handles diacritic languages itself, and the iOS keyboard is quite robust when it comes to accented characters in the standard system font. Xcode even supports the copying and pasting of most (if not all) of these characters directly into string literals.
tl;dr Use the system font. ([UIFont systemFontOfSize:mySize];)
Is there any other way to localize iPhone apps beside the use of Localizable.strings? Can I use Google Translate or something like that?
I have my application written in English, and I have created Localizable.strings files for about twenty languages. I have the English Localizable.strings working perfectly, and I have tried Italian as well. Is there any way to translate these Localizable.strings to the rest of the languages automatically?
I mean is there any program or something to do the job for me?
In short: No, there is no program for that. It's the same problem as translating any text: You need to understand the meaning to give useful translations.
As a quick fix, you can of course simply take the strings in your Localizable.strings file and copy them into a Spreadsheet, then run one column through Google Translate and copy the result back. Then reverse the procedure and you have a translated Localizable.strings. A regex for doing this would be:
^"(.*)"\s*=\s*"(.*)";$
that works fine in eg. TextWranger with grep mode on, then you can replace the text with
\1\t\2
to create a the tab-delimited file from a strings file.
I still suggest you invest in a native speaker of each language to double-check the translations, or your app will become a laughing stock. Google Translate just can't replace a real human yet...
To localize your app you can use Localizable.strings or use localized XIB.
I don't use the second approach because it is more cumbersome to manage.
With Localizable.strings you have to code a little bit more but I prefere it.
To translate I think you can use google translate (I do that) and build the file for each language.
If you want to use an online translator, remember that it can be not always available and your user must be connected all the time.
So my advice is to build all the language files since they are managed by the OS and you will have a more reliable solution.
You should create Localizable.strings for each language and translate them with any translation tool