I am trying to internationalize an iPhone app that was written few years ago and at that time unfortunately internalization was not the priority. As there are lot of nib files I have used ibtool to programmatically generate the nib files for each country. After running the ibtool utility i had to open up the project.pbxproj file and had to insert manual entries for the spanish language. Since i have to update lot of entries i did not choose this route.
I wanted to know how can i generate region specific nib file and have the entries reflected in the project.pbxproj file.
Secondly, I was unable to use gestrings option as the code doesn't use the NSLocalized method every where the text the is hard coded. while i prefer this option is there a safe mechanism to find out all the strings in the code base that can be internationalized?
Apologies for the long question. Any recommendations on how should i go about internationalizing the app?
Regards,
I solved this problem recently and came across the following links iphone-applications-localization-guide and ibtool-localization and Merging-changes-into-a-localized-nib-file
maybe it will help you.
Related
I am using a command line tool (ng-xi18n) to extract the i18n strings from an angular 2 app I wrote. The output of this command is a messages.xlf file. Coming from a .po background, and being not familiar with .xlf, I assumed that this file is the equivalent to the .pot file (correct me if I am wrong).
I then assumed that if I want to translate my app, I had to cp messages.xlf messages.de.xlf to have a copy (messages.de.xlf) of the template file (messages.xlf) where I can translate each message into German (hence the .de.xlf).
After translating some dummy texts and running the app, I saw that it worked as expected, so I quit translating and continued developing the app. After some time, I added more i18n strings, and eventually thought that I had to update my template. And this is where things got hardly maintainable. I updated the template messages.xlf file, and quickly was wondering how I could update the new strings to my already translated messages.de.xlf file without loosing my progress.
When I was developing using .po files, this was no problem thanks to good tools like poEdit, but I didn't find anything comparable for .xlf. After trying some tools, I thought that the best choice would be Lokalize, but I didn't find a possibility to merge the template file to already translated (but outdated) files either.
Up to now, this was rather an essay than a question, so here's a quick summary:
Is the workflow of dealing with .xlf files really comparable to .po as I initially thought (described above), or is it completely different?
How am I suppose to update my already translated files?
What are the best practices dealing with .xlf files?
What are proof of concept tools to work with .xlf?
Sidenotes:
The Lokalize handbook was not helpful at all. I see a lot of functions that sound promising, like:
"File" > "Update file from template". I did not find anything in the handbook to explain this function. If I click on this, nothing happens.
"Sync" > "Open file for sync/merge". This seems to be a function to merge two similar files (by multiple translators) rather than a tool to update the translation file from a template. Even though there is a tooltip in Lokalize's primary sync tab, notifying me about "x unmatched entries", I just couldn't find anything to append those unmatched entries to my .de.xlf file.
[Update] Turns out, I had similar issues as in this question. After downgrading my version of Lokalize to the suggested one, many issues (including the ones mentioned in the question) disappeared. However, now the "Update file from template" option is greyed out, and I don't know why.
I also tried OmegaT, which does not work at all on my platform (Ubuntu 16.04).
[Update] Virtaal works great for merging new strings from a template, but the UI in general is very poorly designed...
Googling did not help, as every hit seems to be related to XCode or something.
Thanks for any help in advance, I really appreciate it
I wrote a small npm command line tool called xliffmerge.
In principle it does the same, that Roland Oldengarm does with his gulp tasks described in his blog article.
It is free and you can have a look at it at https://github.com/martinroob/ngx-i18nsupport#readme
The best workflow automation solution I have seen described so far is from Roland Oldengarm's blog entry "Angular 2: Automated i18n workflow using gulp". To summarize, in a few dozen lines of Gulp code he created the tooling to handle some of the challenges you faced. Specifically it runs ng-xi18n to extract the messages; creates an English translation with sources copied to targets; updates existing translations by adding new trans-units, keeping existing ones, and removing missing ones; and then exposes all xlf files as TypeScript string constants. These last strings can then be imported to supply the bootstrapModule with its translation provider options.
Caveat: I have not used this exact solution (and code) myself, but I was able to expose generated xlf as TypeScript strings and use them in an app in a manner similar to what he described. As for maintaining translations, I have leveraged IntelliJ IDEA (WebStorm) file comparison features and Counterparts Lite (for Mac) for that. My own efforts are still in early stages but are working end to end for an application that is in active development.
Official Angular docs are now updated for Internationalization (i18n) at https://angular.io/docs/ts/latest/cookbook/i18n.html including a section specifically for creating a translation source file with the ng-xi18n tool.
I am an absolute beginner, so I am sorry if this question has been asked before and I simply couldnt find it because I was lacking the right search terms. Feel free to point me to the right posts and delete this one her. So apologies in advance.
I am looking to program a software that imports a list and links every word or sentence on that list to an audio file. I then want to export the whole thing: the list, the audio files AND how the relations between the words in order to use everything with a different app, programmed in a different programming (that is all yet to come. it will probably be in ruby)
Since I will probably not be able to open coredata files with ruby, which file format will be the best for me, so that I can use it in ruby etc.? or will I have to save all audio files individually, as audio files and have a separate txt file that links the words to the files? This sounds... wrong? :(
Sorry I am so lost right now!
You can use json file to hold all your data. It is widely accepted as a data interchange format. But better not to embed audio files in another file. Instead you can save path to you audio file.
Some colleagues, now departed, had the habit of adding new classes within a related class file.
This makes refactoring painful.
Is there a tool, perhaps within XCode or AppCode or just a simple script, that will split up these monster files?
It appears there is a tool to help with this in AppCode, but it only semi-automates the process.
I'm using AppCode 2.0, I don't know if the same tool is available in AppCode 1.x.
To extract one class from a file to a new file, right-click the#interface or #implementation line and select Refactor > Move. Alternatively press F6 on that line. You can now enter a new file name, though you probably want to copy+paste the class name in here. At this point you can also select any defines you want to move.
I have done some work on a script to extract all classes in a file. I'd love to share this one day, when I get the chance to remove our clients code from the unit tests!
I don't think so there is any tool for this. However you can write your own osx application for doing the same.
The application will ask to browse the file, and it will search for #interface....#endand#implementation....~#end` and will create a file from this. If a single file contains two classes then it will result in for files (two headers and two implementation). Then the original file can be deleted manually or automatically.
I think this above task can be completed in few hours.
Here you can go for save the original file in a folder, just in case you want to rollback.
There's a program called PPStream which is currently only available in Chinese, it allows for access to a myriad of ad-supported movies and TV series. The problems is that it is in Chinese and menus are indecipherable.
Is it possible to hook into the part of Mac OS's API that puts text on the screen so that it routes it through a wordlist first, translating the text into English? Would the API hook be able to differentiate the different applications calling the API?
I have no experience at all with Mac APIs, just pondering on if this is worth pursuing or not.
Thanks.
Edit: The reason I would like to do this at API level is that I need to dynamically dispatch HTTP queries with a list of strings to be translated (movie titles Chinese -> English), and the edit-the-i18n-file approach wouldn't do. Any other suggestions?
I haven't downloaded, installed or run PPStream myself so I'm speaking "out of my rear end" in a sense, but there are a number of ways to localize an app. But you really need to have access to the raw, uncompiled code and project to do it correctly.
The three most likely ways the string resources are saved are these:
1)
The app may have a strings file from which it fetches the strings to be displayed in the interface.
You may be able to make a copy of this strings file and set it to English or whatever language you choose.
2)
The strings may be baked into the code itself. This is generally a NO NO for commercial grade MacOS & iOS apps, but lazy and/or inexperienced developers can do this especially if they don't think their app will ever be used in other languages.
3)
The most likely set up is that there will be a folder hidden in the application package, inside the "Resources" folder, that has named like "en.lproj" or "English.lproj" or "de.lproj" or "zh_CN.lproj" or "zh_TW.lproj" (these last two are especially likely if this is only in Chinese).
Inside those folders will be localized XIB (or older NIB) files. And if you make a copy of this folder and then modify the newly made copy to add your new language.
Options 1 & 3 are ones you might be able to copy and then modify, but then again it might not work (especially these days when there's code & app signing). I've never tried this without an accompanying project, so if you have success, you should comment your question and/or this answer and let us know.
If you scroll down to the section 'Writing to Files and URLs' at this link, would the path varaible have to be a file on disk? Is it possible to write to a file in the bundle or must it always be deployed first?
You can write files to the application bundle as much as you'd like. Just get the path of the file through NSBundle's pathForResource:ofType: method and you can write to that file. If you want just the directory of the bundle, use resourcePath.
You don't want to do this, though. There are various reasons, but you'll break code signing, which is a big one. You should use the established conventions instead (such as writing to Library:Application Support:Your App).
EDIT: For a (possibly) more convincing reason of not to do this... When I was first learning Cocoa programming, I saved to the bundle because I didn't want to bother with the Library. It got really annoying, though, because every time you make a change to your program, you lose all of your saved data/settings for that program (assuming you're not using NSUserDefaults for preferences). I kept having to move it over from the old version to the new one. By using the Library, you don't have to worry about this.
The bundle is on disk; it's just the ".app" directory. You should not write to files in this directory, however. While currently possible on Mac, it will break code signing. On iPhone, you already can't write into your own bundle, and we should expect to see this limitation in the future on Mac. You should write your application files into various directories under ~/Library or ~/Documents as appropriate. See the File System Programming Guide for guidance.