I can't export for localization, I just get a "Localization failed to read a strings file" error.
The system log says:
2015-06-07 01:41:48,305 Xcode[1914]: [MT] DVTAssertions: Warning in /SourceCache/IDEFrameworks/IDEFrameworks-7718/IDEFoundation/Localization/IDELocalizationWork.m:434
Details: Failed to read strings file "/var/folders/vh/z7jrdtc16mv_ml4rdf3c_yf40000gn/T/Xcode3SourceStringsAdaptor-8B1BF14F-E8BF-4354-9FB6-BFF843BD6623/Localizable.strings", underlying error:
The data couldn’t be read because it isn’t in the correct format.
Object: <IDELocalizationWork>
Method: +readStringsWorkForContext:
Thread: <NSThread: 0x7fa8a250a200>{number = 1, name = main}
Please file a bug at http://bugreport.apple.com with this warning message and any useful information you can provide.
But I have no idea what file "Localizable.strings" is.
These steps didn't work:
Found "Localizable.strings" in Base.lproj and deleted it. It was completely empty.
Deleted the whole folder specified in the log message.
Clean and Clean build folder.
Running genstrings first to generate missing .strings-files. genstrings complained and said my strings weren't literals in the calls to NSLocalizedString. Uhh... they all look like this: private let ALERT_REMINDER_FIRED_TITLE = NSLocalizedString("ALERT_REMINDER_FIRED_TITLE", tableName:"ReminderHandler", comment:"my comment")
I figure that Localizable.strings is supposed to contain someting, like /** no localizable strings **/ or something. The problem with that is that my project doesn't even contain the file, it's being generated as completely empty.
Seems that unfinished and commented out calls to NSLocalizedString interfere with export for localization.
For me it was like key = "your string"; that worked in swift 3.
No quotes for key. Semicolons at the end.
I had the same problem when tried to use NSLocalizedString with own NSBundle specified. Seems Xcode won't work if you use localization macros with different form than NSLocalizedString("Some key", comment: "Some comment"). I have fixed this by just redefining the NSLocalizedString function like that:
public func NSLocalizedString(key: String, tableName: String? = nil, bundle: NSBundle = NSBundle.mainBundle(), value: String = "", comment: String) -> String
{
return yourBundleHere.localizedStringForKey(key, value: value, table: tableName)
}
Replace yourBundleHere with NSBundle.mainBundle() or what ever you want.
Check if there are redundant double quotation marks in your Localizable.strings file, then remove them.
The problem for me was that I had completely empty xx.strings files - I'd manually cleared them out.
Add this line at the top of any empty xx.strings files, and the export works again:
/* No Localized Strings */
Had the same issue.
In my case it was caused by an NSLocalizedString that used a variable passed from the server as the key instead of actual strings. The system still scans commented code so anything short of deleting the lines of code will not work.
Related
Since macOS 11.3 broke my Perl script which I have been using to generate Sparkle appcasts for the last 12 years, I decided to instead start using the generate_appcast tool which has since been provided with Sparkle. Invoking generate_appcast with no arguments, I get some brief documentation which I interpret to mean that I should provide two arguments:
a -f followed by the path to my Sparkle private key file
the path to a directory of several recent versions of my app, all zipped
So I created a new directory and copied zip archives of the three most recent versions of my app into it. Those are the .zip archives, notarized by Apple, which I upload to my site for users to download.
Then I ran this command:
Air2:~ jk$ generate_appcast -f /path/to/My_Sparkle_priv.pem /path/to/directory/of/zips
The result:
Warning: Private key not found in the Keychain (-25300). Please run the generate_keys tool
Error generating appcast from directory /path/to/My_Sparkle_priv.pem
Error Domain=NSCocoaErrorDomain Code=256 "The file “My_Sparkle_priv.pem” couldn’t be opened." UserInfo={NSUserStringVariant=(
Folder
), NSURL=file:///path/to/My_Sparkle_priv.pem/, NSFilePath=/path/to/My_Sparkle_priv.pem, NSUnderlyingError=0x13a637e10 {Error Domain=NSPOSIXErrorDomain Code=20 "Not a directory"}}
Apparently it is not recognizing the key file I provided, and also oddly implies that it expects a directory instead of a regular file. In the brief documentation, there is an example marked [DEPRECATED] which omits the -f before the path to the key file, so I tried that but got the same result. I also tried putting the path to the zips first, but that result was even worse.
My key file is, I think, a pretty standard .pem text file that begins with the line -----BEGIN DSA PRIVATE KEY----- followed by 1133 ASCII characters, etc.
Where did I miss the boat?
Astonishingly, this seems to be due to an obvious programming error in the Sparkle generate_appcast Swift source code. In attempting to remove elements indexed N and N+1 from an array of command-line arguments, the code removes element N, and then removes element N+1, which of course removes elements N and N+2 instead. After I fixed this programming error, the problem is solved.
After I do some more head-scratching and maybe consulting with others smarter than me, I shall submit a pull request or whatever to the Sparkle project next week.
I executed make all --print-data-base and I see many lines containing:
...could not be stat'd
What is that?
your command to to print data base catches all, and some of the files are not of the type to return specific information as requested, so such files return a null because of invalid type: meaning no information of such files; not an error just a debugging concept
I am trying to write a Mac app that converts files. I am stuck at the beginning because my app cannot open local files, at least while running in the debugger. I use the NSOpenPanel to create a valid file NSURL:
“file:///Volumes/Seagate_1tib/projects/dataskunk/wasteproduct.xml”
But somewhere in xcode, or the debugger or whatever, this gets mangled into
"/Users/charlweed/Library/Developer/Xcode/DerivedData/dataskunk-ghkiumvdkopxarhavynetidlqxio/Build/Products/Debug/file:/Volumes/bigdrive/dataskunk/wasteproduct.xml"
Reading the file then fails with a "No such file or directory error".
How do I prevent this mangling during development?
For example, this gives the error, no matter what file is chosen:
let fileResult = openFileDialog("Choose File", message:"Message")
let xmlInFileURLOpt: NSURL? = NSURL.fileURLWithPath(fileResult)
if let xmlInFileURL = xmlInFileURLOpt
{
var xmlFileError: NSError?
if !xmlInFileURL.checkPromisedItemIsReachableAndReturnError(&xmlFileError){
println("\(xmlFileError)")
return
}
}
The answer is that NSURL.fileURLWithPath() does not take a URL-path as an argument, only a filesystem-path. So "file:///Volumes/disk/file.xml" is wrong, "/Volumes/disk/file.xml" is correct.
The mangling is NSURL prefixing the current directory onto what it thinks is a relative filesystem-path String.
I'm trying to localize my app, and I have the following code:
self.arrayLabels = [NSArray arrayWithObjects:NSLocalizedString(#"This is a test", "this is a test"), NSLocalizedString(#"I want my strings to get added to localizable strings file", "strings comment") , nil];
So, basically, from what I understand, this should be it, I click Editor > Export for Localization and the strings should be there on my XLiff file. But, they aren't.
I have two languages, english and portuguese, both localizable.strings files are empty.
Am I missing something?
I discovered that I had a few errors and that is why I could not export from the menu.
I suspect that the error messages are not being returned.
It turns out that the menu is calling existing command line tools so by a process of elimination you may be able to fix your export.
Here are the steps I took to fix my issues. Hopefully they will help you.
Run the command line equivalent
xcodebuild -exportLocalizations
If you have errors xcodebuild may give file names and line numbers so you should be able to fix the issues.
I had one error that did not have any details.
I then switched to using genstrings as that is what xcodebuild appears to be using in a loop.
find . -name '*.m' | xargs genstrings -o somePath/en.lproj
this gave the same error
To get the file with the problem I ran each file separately in a loop.
for f in `find . -name '*.m'`; do
echo "processing $f ...";
genstrings -o somePath/en.lproj $f
done
That gave me the name of the file that had an issue.
It turned out that genstrings did not like a special character I was trying to print using a unicode character \U000000B2.
For the exported XLIFF to contain your localized strings, a few conditions have to be met:
The keys must be present in your localized strings file. In your case these files are empty. Which will explain the problem.
You must use the keys as string literal with the NSLocalizedString macro. For example:
This is the correct way:
NSLocalizedString("some_key", "")
This will not work:
let key = "some_key"
NSLocalizedString(key, "")
In Xcode, use the Editor-->"Extract for Localization" menu which will generate the .xliff files (one per language selected). The .xliff files are sent to a translation service for translation. Once the .xliff files are updated by the translation service, you need to import it back into the app using Editor-->"Import Localizations". Once this step is done, for each language, you will find a xx.lproj/ folder with the results of the translation.
I'm trying to load hunchentoot via quicklisp in slime, and getting the following error:
READ error during COMPILE-FILE:
:ASCII stream decoding error on
#<SB-SYS:FD-STREAM
for "file [redacted]/dists/quicklisp/software/rfc2388-20120107-http/rfc2388.asd"
{100607B723}>:
the octet sequence #(196) cannot be decoded.
(in form starting at line: 29, column: 29,
file-position: 1615)
[Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR]
I get this when trying to run either:
(ql:quickload "hunchentoot")
Or simply:
(ql:quickload "rfc2388")
It seems that others are getting this too. I found one hint at a possible answer, saying:
The system file is encoded as UTF-8.
I'm not sure how to configure things so that SBCL on Windows starts with
UTF-8 as its default encoding for loading sources, but that's what you
need to do.
From there, I've tried (based on e.g. [this] adding the following to my emacs config:
(set-language-environment "UTF-8")
(setq slime-lisp-implementations
'((sbcl ("/opt/local/bin/sbcl") :coding-system utf-8-unix)))
(setq slime-net-coding-system 'utf-8-unix)
But... I still get the same error, even after completely re-starting emacs, to make sure I had a fresh Slime that was reading the above config.
So, what am I missing, and/or otherwise how can I get this to load?
Thanks in advance! (More thanks to come for a successful answer. ;)
Have you checked your locale settings? Emacs configuration only tells it what coding systems to set for communication between SLIME and SWANK.
You can check for locale settings with /usr/bin/locale, for example:
navi ~ » locale
LANG=pl_PL.UTF-8
LC_CTYPE=pl_PL.UTF-8
LC_NUMERIC=pl_PL.UTF-8
LC_TIME=pl_PL.UTF-8
LC_COLLATE="pl_PL.UTF-8"
LC_MONETARY=pl_PL.UTF-8
LC_MESSAGES=C
LC_PAPER=pl_PL.UTF-8
LC_NAME="pl_PL.UTF-8"
LC_ADDRESS="pl_PL.UTF-8"
LC_TELEPHONE="pl_PL.UTF-8"
LC_MEASUREMENT=pl_PL.UTF-8
LC_IDENTIFICATION=pl_PL.UTF-8
LC_ALL=
navi ~ »
Mine is setup for UTF-8 everywhere, as you can see, except for displaying 'C' messages.
Try this:
change into the .../quicklisp/dists/quicklisp/software/rfc2388* directory and load rfc2388.asd into a text editor.
Move down to the :author parameter of the defsystem form. Replace the author's name by the name given at the top of the file.
Store file using ASCII encoding.
Of course, when a new version of the library is published, the workaround gets lost. Or else store the modified project in local-projects.
With the original UTF-8 encoding still in effect, the DEBUGGER should present an INPUT-REPLACEMENT option to replace offending input characters by a replacement string. Choose that option, type "?" or "x" or any string you like at the prompt and then ENTER. The load then completes. Of course, that is not something you would like to do every time.
So the best idea is probably to send an email to the author and ask to provide an ascii version for quicklisp.
There should be a .cache directory in your HOME that contains all the fasl files. Sometimes removing those old fasl files seems to work for me when something goes wrong with compilation.