When I export my XLIFF file from Xcode, none of the strings I declared with NSLocalizedString have a < target> element. The strings generated from my storyboard do have a < target> element. Has anyone seen this before? Google reveals nothing.
String:
let oops = NSLocalizedString("Oops!", comment: "Alert box header")
Resulting XLIFF:
<trans-unit id="Oops!">
<source>Oops!</source>
<note>Alert box header</note>
</trans-unit>
I don't know specifically about XCode's behavior, but <target> is optional, so this is legal (although possibly inconvenient) XLIFF. (source: xliff 1.2)
You should be able to create add a <target> element during translation without problem, and most translation environments that support XLIFF should be able to do this as well.
The are a lot of useful tools that you can use to automatically write the target. Check on the App Store looking for xliff... some of these tools are also free.
As example, XLiffy seems to be easy enough to use.
Related
I'm trying to localize a small Xcode project (Xcode 9 and Swift 4). In that project there are places where I use plurals, so I need to localize them, too. To do that, I use stringsdictfile. In code I use localizedStringWithFormat(_:,fromat,:argument) static method on a String. Here how my code for a plural looks (I just print the words for testing):
let localizedString = NSLocalizedString("%d apple(s)", comment: "The number of apples")
print(String.localizedStringWithFormat(localizedString, 0))
print (String.localizedStringWithFormat(localizedString, 1))
print(String.localizedStringWithFormat(localizedString, 2))
print(String.localizedStringWithFormat(localizedString, 10))
Then I create a stringsdict file. It looks like this:
In the video from WWDC 2017 (session 401) about Localization it is said, that when we use stringsdict file for localizing plurals into other languages (in this case, I want to localize it into Russian) we just need to give values for the cases of our development language (English), and when exporting for localization, Xcode will automatically create cases in an XLIFF file for the language into which we want to localize. So I've given values for zero, one and other (in the demo from the session values are given only to keys one and other, however, I don't thing that that's the reason of the problem).
Now, when I create an XLIFF file it looks like this (only the part of apples):
As you can see, Xcode doesn't generate cases for a particular language automatically (for Russian it should have 4). I'm using stringsdict files as well as trying to localize plurals for the first time, so I can't figure out what I'm doing wrong. If you know where is the issue, or have any suggestions, I would appreciate your help.
There is little you can do in Xcode. XLIFF just holds the segments that it's been told to hold.
A better approach would be to rephrase the strings so that plurals are less an issue, like:
not "%d apple(s)"
but "number of apples: %d"
You should file a bug at apple about that.
Unless you have a requirement to work with the XLIFF from Xcode, I suggest you don't and instead rely on the string files.
I've been searching all over the internet and there doesn't seem to be a clear explanation on how to localize strings using SpriteKit. Only seeing tutorials for people using the interface builder, but all I really want is, imagine this:
I have an SKLabelNode called label. And I define the text like:
labl.text = NSLocalizedString("titleOfTheScreen",nil)
So basically what I think I have to do is add the new language in the Project settings. Then, I add a new Strings file called Localized, and add it to the new folder.
But what happens to my English language? There's no file for the original one
First you have to add a Strings File:
Then open the project settings and add a new language:
Mark your added strings file as target:
Find the newly added localising file. (English is automatically added)
From your screenshots I can see that you have "File.strings" file. You should have created "Localizable.strings" file.
Also, I can see that you have the (Base), (English) and (German) strings version. Why do you think English is not there?
In each of the files you should put strings like that:
"titleOfTheScreen" = "blah-blah";
Replace "blah-blah" with the proper translation in each of the strings files. It's important to note that the semi-colon at the end of the lines in strings files are mandatory, otherwise Xcode would issue some really funny error messages. This is easy to overlook if you're programming in Swift and trailing semi-colons are not mandatory.
I am converting DITA to XLIFF. In my technical solution I have to specialize (modify) xliff-core-1.2-strict.xsd to accommodate few DITA attributes. It means some attributes will go along with "g" tag. For Example:
<g id="00001" newAtt="this is new attribute" xid="009"/>
From the translation side I am not sure how it will work, so my questions:
Is it general practice that LSPs will get different flavor of XLIFF XSDs from different companies?
And is it possible for them to use it in their XLIFF editor by updating updated XLIFF XSD? I tried to explore “Transolution” but did not find any place where to place modified XSD.
Please let me know if you have any thought on this.
Thanks.
Here are my answers to your two questions:
I work for an LSP and I've seen all sorts and flavors of Xliff. Most of them try to stick to OASIS 1.2 transitional schema. Some of TMS/CAT producers added their own extensions. These producers normally provide an XSD so you can validate their Xliffs by adding that XSD to OASIS schema; e.g. SDL extensions to 1.2. When I'm customizing Xliff for a client, I normally do namespaces and provide a simple additional XSD; e.g.:
<trans-unit id="0" translate="yes" resname="msg_foo">
<superduper:uri>http://foo.bar/iJKLM9</superduper:uri>
<source>This is supposed to be a <superduper:g id="00001" newAtt="this is new attribute" xid="009"/> example.</source>
<target state="new"></target>
</trans-unit>
Most of the TMS/CAT tools are very basic (and closed) when it comes to their Xliff filters (or any of their filters for that matter) and I'm sorta kinda sure that they ignore your customized XSD.
Transolution is a very nice tool and my favorite Open Source translation tool. Unfortunately it's been long abandoned and has plenty of defects and shortcomings.
Anyway, if you provide a sample file, I can tell you what happens to non-conforming tags when it's imported into one of common, major CAT tools.
One final note; <g> seems to be retired in Xliff 2.0.
Forget about Transolution for one thing. I would try it with Trados, MemoQ or MemSource. Those are some of the big tools used in the translation business.
Personally I never got an XLIFF with a XSD, nor do I think Trados can handle it.
What do you need to change in the XLIFF?
In Delphi there is an option VersionInfo->Language->Locale ID when viewing project properties.
I was wandering how to set such property for a program being compiled under Free Pascal.
Any solution is welcome: command line argument or preprocessor directive such as {$key value}; equivalent to Delphi.
If you can build your projects using *.lpi files then I would try to add the following into your project's Project.lpi file. In the following snippet is shown how to set the project's locale ID (for Windows platform) to 0405 (Czech).
<?xml version="1.0"?>
<CONFIG>
<ProjectOptions>
...
<VersionInfo>
<UseVersionInfo Value="True"/>
<Language Value="0405"/>
<StringTable ProductVersion=""/>
</VersionInfo>
...
</ProjectOptions>
...
</CONFIG>
Or if you are using Lazarus IDE then you might use to Delphi very similar settings tab which you can open from Project / Project Options ... and as in Delphi go to Version Info where is the Language selection combo box available if you include the version info into the project.
Not 100% sure this will work, feel free to vote me down if this doesn't work.
Lazarus will inherit the locale settings it starts with.
You can set the locale info prior to starting Lazarus in Linux/OS X using the command line:
export LC_CTYPE="pt_BR"
export LANG="pt_BR"
export LANGUAGE="pt_BR"
./lazarus
Your compiled application should inherit these settings.
The answer is inspired by this workaround to an error has since been fixed.
I recommend you have a look at the fpc forum as well and ask the question there.
Don't forget it include details like the platform (Linux/Windows/OS X) and the exact version of FPC and Lazarus you are using as well as the actual Locale that you want.
Better answer
From: http://forum.lazarus.freepascal.org/index.php/topic,5924.0.html
Finally, I managed to find a simple and effective way to make my application localizeable. It uses just one unit and no code.
1. Add unit "defaulttranslator" to your uses list.
2. Enable "i18n" in "Project Options" and set "PO output directory" to "locale" or "languages". You can put translation files right into application folder, but that would just make a mess. Don't forget to create an appropriate folder.
3. Add components to the form. If you already have all components on your form, you'll have to move it a little bit, so it's modified.
4. Save your project.
5. Now there should be .po files in your "locale" or "languages" folder. For different languages files should be copied and renamed like so "project1.XX.po", where XX is language code (e.g. "en", "de", etc.).
6. Translate .po files with translation software, and generate .mo files. I suggest to use POEdit.
7. Run your application, and the translation to be used will be chosen by your regional locale settings. If you need to test other language - just start your application with following command line parameters - "-l XX" or "-lang XX", where XX is a language code.
This method is not very versatile, but it translates resource strings and LCL component properties.
I am attempting to use InAppSettingsKit to manage my settings. This uses the Settings.bundle with a .plist file and the .strings files for each of the languages being translated.
I can confirm that the translation of my strings is working properly outside of my application, using the Setting application. But when I am in my application, the translation is not occurring.
I think it comes down to code like this, from the InAppSettingsKit class IASKSettingsReader, with a couple logging statements that I thought my be helpful:
- (NSString*)titleForStringId:(NSString*)stringId {
NSLog(#"%#",[_bundle localizedStringForKey:stringId value:stringId table:self.localizationTable]);
NSLog(#"%#",[_bundle localizedInfoDictionary]);
return [_bundle localizedStringForKey:stringId value:stringId table:self.localizationTable];
}
If I understand correctly, this should be using a table with the name self.localizationTable as the source of the translation. This value is simply "Root". It's not a path to the Root.strings file in the selected language, so I am guessing that the method localizedStringForKey:value:table: must be using some global system reference that points to the correct path.
I have confirmed that the strings file name is "Root.strings" all around, with a capital R, including in the Root.plist file.
[_bundle localizedInfoDictionary] returns (null); It is doing this for two language settings of English and French.
I'm not sure how to debug this. Thanks for any help you can give.
I'm using InAppSettingsKit with localized text with no problems. Two things I can think of that you could check: are your Root.strings files located in the correct subdirectories of Settings.bundle (en.lproj and fr.lproj for English and French?
Is there a "Strings Filename" entry in your Root.plist? It should simply contain a string with value "Root"
It has been quite some time since I resolved this, and at the time, I didn't fully understand it. But, in the interest of closing out this question, I'll point to the following documentation for future reference:
NSBundle Class Reference
which refers to the following:
Resource Programming Guide
In the second document, refer to the section "String REsources -> Loading String Resources Into Your Code"
The solution contains a properly configured Root.strings file, which shows up in the file list like this: