I am facing a very obscure issue.
I've got an app that needs to be localized in three Languages, English, French, German. There's multiple localization files as I've got multiple storyboards ( each storyboard has one for each language).
Everything works great and things translate properly except for ONE file in ONE storyboard in ONE language. So this specific storyboard I call "Authentication" works for all languages except for the German one.
I've checked. the file is:
included in all targets
is also found in Build Phases copy phase
has the correct name.
has the correct formatting (in fact i am not allowed to build at all if the formatting is not correct in this version of Xcode.)
I am out of ideas and resorting to asking here to see if theres anything i might be missing in my series of checks.
Thanks all
SOLVED.
The answer lies within my third point
has the correct formatting (in fact i am not allowed to build at all
if the formatting is not correct in this version of Xcode.)
Beware everyone. This might seem like it is the case but it does not apply to everything. If there's a syntactic error in the Localizable.strings file, xcode will let you know and refuse to build.
HOWEVER if there's a syntax error in the YourStoryboard.strings file, the process of building will go on UNHINDERED.
Since an issue in syntax was halting everything for Localizable.strings i was wrongfully assuming that such a check would take place for all translation files. It doesnt!
Hope this saves someone in the future
Related
TLDR: Xcode generated storyboards for each language, however I want the "old"(?) *.strings files. How?
I am currently in the process of localising my storyboards. After I enabled everything, Xcode generated another storyboard alongside the original (english) one for me to localise. I was surprised, I expected a Localizable.strings file, like the apple documentation still states as of April 3, 2021:
For storyboard and XIB interfaces, select the user interface files (files with a .storyboard or .xib filename extension). Xcode adds a strings file to the localization folder that contains the text to translate, as well as comments that describe the user interface components. For example, if you add German to an iOS app that uses storyboards, LaunchScreen.storyboard becomes a group containing a LaunchScreen.storyboard (Base) and LaunchScreen.strings (German) file.
I searched around the internet, in apple developer forums, watched both WWDC18 and 19 talks about localisation in Xcode, but did not find a single mention of translated storyboards.
After the initial translation, which works great due to the simplicity of just filling everything in, it gets frustrating however, since every layout change needs to be repeated for every language. This can't be intended, there must be a better way, right? Sadly, I didn't find anything. Even a hint to a piece of documentation regarding these storyboard copies would be greatly appreciated. Thanks!
There are some screenshots of the possibility to convert these two formats via a dropdown, like the third picture in this post. However for me, there is no dropdown next to the language item when I click the storyboard, neither on the group, nor individual base or localised ones:
Is this a bug or am I missing something here? I am using macOS Big Sur 11.2.3 with Xcode 12.4 (12D4e).
Turns out, you need to use the Base Localization feature, the dropdown then appears and you can convert existing storyboards to *.strings files.
I can see that this is a recurring problem with all sorts of Xcode versions. I'm using the latest non-beta build (9.2 9C40b).
I have already localized in Spanish. Doing that involved successful exports and imports of xliff files, with same Xcode. So what changed?
I am now trying to localize to another language. This is a showstopper. Any hints? I have looked through all the posts about previous versions crashing, and have not found anything that works.
(And before you mention it, I am done and over with genstrings. If it exists anymore.)
I've discovered that large .xliff files (more than about 6,500 lines or 1,200 <trans-unit> elements) cause Xcode 10.1 to crash consistently near the end of an import operation.
The work-around is to manually split the .xliff file into two distinct .xliff files, each containing a subset of the <file> elements in the original file. You can then import the two resulting .xliff files into Xcode separately without crashing.
Do not translate "bundle name"
I wanted to translate to Greek Language and every time I was importing xliff files, Xcode was crashing.
I realized that the problem was, that I was also translating "bundle name".
If you did the same mistake, open xliff file, find:
<trans-unit id="CFBundleName">
<source>NameOfYourApp</source>
and delete the line
<target>...</target>
After that everything worked perfect for me!
Here's a workaround. Select your project icon in the Project Navigator. Select Info at top (as opposed to Build Settings). Under Localizations, click the + button and add your new language.
Xcode will create the new .strings files and fill them up with pre-existing translations. (If there are any.) Strangely, for me, some of the new .strings files were filled in with English, some with Spanish.
In any case, you have the new .strings files and can manually paste in the translations for the new language. If your app doesn't have too much user-facing text, this isn't onerous.
But really, with this problem going back to Xcode 4 (!) one would think it would be fixed by now.
it's a late answer I know, and I'm using Xcode Version 10.1 (10B61) already.
In my scenario, I added Chinese Hong Kong (zh-HK) language under Project > Info > Localization and exported successfully then sent to the agency for translations. After few days they sent to me Chinese translated text within. At that point, everything seems correct for me by eye. But I've tried 10 times to import file and it crashes 10 times without exception! Which makes me sick. I use to checked to see the difference between 2 document via Apple's File Merge App. I understand that agency geniuses added few missing <\target> tags. Hmmm, that means while exporting Xcode didn't add for some translations <\target> tag. Interesting...
I removed those unnecessarily translated tags and checked everything was equal in 2 documents except translations of the words to the Chinese language.
Tried to import again. Then BOOM! It works like a charm! I was surprised by this. It's so weird that Xcode never shows me a descriptive message about my mistake. Probably, It's just a parse error for Xcode.
Whatever, I hope this will work for someone else.
Best.
I have searched now quite a bit on Stackoverflow for an answer, but I can't seem to find an adequate one.
So, I am localizing an App with XCode. Everything works fine, I have localized a storyboard and everything. The last part which needs to be localized are the labels and buttons in XIB Files. Here I have the following Problem:
XCode Offers me to create localized Xib Files for every language or to create strings files. Both options are fine with me, but none seems to work. One answer to a similar question stated that this does not work my design. If so, why does XCode give me the option to do it in the first place? And, what is a good and easy solution for this?
And I am using Swift, not sure if that really matters, I just thought I mention it.
There is a known issue with recent versions of Xcode where the simulator would not correctly pass the language information to the app, so it seemed as if localization was not working. If that is your problem, there are two workarounds:
try your app on a device and confirm switching the language brings up your localized strings.
force the language via your build scheme (Product => Scheme => Edit Scheme... => Run => Application Language)
I have read a few tutorials about iOS's tools and processes for i18n/l10n, and am unpleasantly surprised with what I'm seeing. It seems there isn't a solid way of externalizing user-facing strings out of objective C files. Am I missing something?
Description of the problem:
There is a tendency to place English strings directly into the .m file, and the Apple documentation seems to encourage this. While this is also possible in Android, as least in Android there is a clear distinction between externalized and non-externalized strings. With iOS, on the other hand, code that calls for a string tends to look like this:
NSLocalizedString(#"There was an error loading the image.", nil)
In this case, "There was an error loading the image." is the key for this string resource. Therefore if I want to make another reference to the same string in some other place we have to again write code like this:
NSLocalizedString(#"There was an error loading the image.", nil)
But now I have to make sure that I spelled these two strings the same and there is no compile time check to help me confirm that. I could write a helper function called createErrorString, but that's not fun. And I could replace "There was an error loading the image." with a more sensible key like "ERROR_IMAGE_LOAD", but that does not seem to be a common practice, and Apple seems to discourage this sensible behavior. Here is what their documentation states:
"A common convention when developing applications is to use a key name
that equals the value in the language used to develop the
application."
It looks like Apple is recommending that you put the full English string in your source code. So I'll have to try to convince my colleagues to go against Apple's guidance.
Now that I've got all of these user-facing English strings (or keys) in the source code, Apple includes a tool called genstrings that parses the .m files, and spits out a Localizable.strings file that I can then send out for translation. This might work if you are only going to get your app localized one time, but in our company localization is an ongoing iterative process. Look at what the Apple documentation recommends:
"For subsequent runs, it is a good idea to save a copy of your current
strings files before running genstrings. You can then diff the new and
old versions to determine which strings were added to (or changed in)
your project. You can then use this information to update any already
localized versions of your strings files, rather than replacing those
files and localizing them again."
That doesn't seem very good. In Android and Windows8, you internationalize your source tree one time, and from that moment on your externalized strings are owned in the xml files where they belong; in iOS they are owned in source code (sort of) and then tabulated into some intermediate file (or is it?) by some crazy tool. Is the Localizable.strings file an intermediate file or should it be committed into git - we are still debating this at my company.
(And from what I can tell, this is only the beginning. In xib-land, which is where 90% of your user-facing strings live, there also seems to be an inefficient mechanism for l10n. Wil Shipley's article describes this at length.)
Does anyone have any suggestions on a good way to externalize strings in iOS? My main question concerns objective-C strings, but answers pertaining to xib files would also be much appreciated. Thanks!
I found the recommendation to name the key like the english string strange, too.
I name the keys, value e.g "Menu1SettingsTitle" = "Settings".
I dont need genstrings tool, just externalize manually.
And no, the string files is not an intermediate step, they should be in git.
However with that approach i noticed three drawbacks:
1) I detected duplicate names, but that can be moved to a common section for strings like "cancel, delete"
2) If you forget to put a string into that language file, it cannot be found and then the key is displayed, which looks very strange, of course. Otherwise with apples reccomendation, If the key is the english word, it looks "only english" but not worse.
3) The translation process is easier if english is always left, instead of "Menu1SettingsTitle". to solve that i put a comment above, but dont know if the translation service would be happy with that.
After a couple of hours searching I decided to use two different approaches: one for the storyboards and one for the text inside the .m files. The result are two files Localizable.strings for the Objective C text and the internationalized storyboard.
The update_storyboard_strings.sh can automatically extract translatable strings from storyboards and update strings files. The source code (by mikezang) can be found at:
http://forums.macrumors.com/showpost.php?p=16060008&postcount=4
For the objective C NLS I use another script around the xcode-tools by Frédéric Sagnes:
https://github.com/ndfred/xcode-tools
I had to call it for each language in order to get the desired results:
python scripts/xcode-tools/update_strings.py --import=MyProject/Base.lproj/Localizable.strings MyProject/Base.lproj/Localizable.strings
python scripts/xcode-tools/update_strings.py --import=MyProject/de.lproj/Localizable.strings MyProject/de.lproj/Localizable.strings
Now put both in one script and add it to your Xcode project as a last build phase.
I'm new to Objective C and (unfortunately) also to the project I am working on. I was given a small sample project that refers to work from my predecessors (in C++) and uses it for an iPhone app (Objective C). Rather than extending the sample (it was quick n dirty and I didn't wanna mess around in it) I created a new project from scratch for my stuff. To get it working I need to set up the same links to the previous libraries as the other one, but although in my settings I can't find any differences to the existing project it won't do the trick.
With the help of colleagues and Google I reached this:
1) The project includes two library files, libyid.a and libvrpn.a, via Xcode's "Add files" dialogue. It automatically added the libraries' paths to the Library Search Paths in the Build Settings and the files show in the projects folder structure in XCode.
As far as I can tell this bit seems not to cause problems.
Edit: if i remove these files from the project I get the same errors. I'm now thinking that XCode can resolve the headers, but can't find the implementation and that the libraries may have been there but not been properly set up?
2) One of my custom classes uses
#import "DisplayYid.h"
I added the path to the file's location to the "Header Search Paths" in the Build Settings and it seems to be found alright. (I also added the file via the "Add files" dialogue at some point, but it didn't change anything, so I left it this way)
Now the problem: in
#interface YidController : NSObject {
DisplayYid *myYid;
// (etc. etc.)
}
the identifier "DisplayYid" seems to remain unknown (Error: Expected specifier-qualifier-list before DisplayYid). In addition, all the class definitions in the headers that DisplayYid itself includes yield
error: expected '=', ',', ';', 'asm' or '__attribute__' before '__declspec'
My knowledge here is unfortunately very limited, but it seems to me that XCode can find the headers in question, but somehow would expect the content in a different format/language?
When I had DisplayYid.h included as a file in the project hierarchy I tried to set its file type in the file inspector to "C++ header" (as suggested by some hits I found on Google for my problem), but this doesn't change a thing.
I feel I am missing some tiny but crucial detail, but am not sure-footed enough in any of this to test around further. Hopefully somebody sees my missing link? And sorry if this is too lengthy, I simply tried to include the detailed steps in case this is were the problem lies.
Thanks in advance for your time ;)
EDIT: This question seems to be the same problem, especially the fact that he gets the error multiple times from files simply copied. But none of the suggested solutions seem to work for me.
It's been a while now, but I got hold of the guy who worked on this previously. It took him an hour, but he found the missing bit: In the project settings, two compiler flags needed to be set:
-DIOS (defining the flag iOS)
-x objective-c++
From there on everything went fine. Since this was a rather project-related question and solution, should I delete it all together?