Xcode 6.3.2 "Export for Localization" Cancelled Newline Characters - localization

Xcode 6.3.2 introduced a new bug in the "Export for Localization" parser: Newline characters (e.g. "\n") included in source language strings, are cancelled out in their corresponding target language strings (e.g. "\n"). This causes the symbol for new line characters to appear in the compiled app, instead of an actual new line.
Fortunately, a previous major bug in the parser is fixed in this release: Error while "Export For Localization.." Xcode 6.3
Anyone have suggestions for a work around, aside from manually altering the strings file for each instance of this bug?

Performing a "find, replace all" works for now.
Open the effected strings file.
Search for "\n"
Select replace and add "\n" to the field.
Click the "All" button.
While this works, its a bit tedious to do every time translations are updated.
NOTE: You may notice that the source string in the .strings file is broken up on multiple lines, as opposed to showing the newline symbol "\n" explicitly in the string on one line. This is also a new bug, but it doesn't seem to effect strings at runtime.
Also, I cannot think of a reason why anyone would want the string "\n" to actually appear in their app, but if you are unsure, you should review each change using git.

Related

HexaPDF glyphs missing as of Version 0.20.2

I'm using HexaPDF to read a file with an AcroForm and fill in this form's fields using the following code:
#acro_form.field_by_name(fieldname).field_value = value
Up until version 0.20.1 this worked fine. As of version 0.20.2, I get this error: HexaPDF::Error (Glyph for "2" missing) on trying to generate the document. The glyphs for all numbers, and for all lower case letters except a, b, and c cause this respective error.
This problem only occurs in my dev setup on Windows 11, not on Linux.
#gettalong or anyone else who might be able to help: Thx in advance!
With the help of #gettalong I figured out the problem:
Some of the text in data/hexapdf/encoding/glyphlist.txt appears to be automatically processed by Windows, inserting line and page breaks in this file which should not be there, and causing other changes to the file's encodings.
I resolved it by editing the above file as follows:
Remove extra paragraph and line breaks and potential invisible characters on entries for controlFF, controlVT and controlSO
Set codes (the part after the semicolon) for controlSUB to blank
Remove blank space on "controlBEL; ", changing this line to "controlBEL;"
Ensure there is a blank space on space, i.e. the line must be "space; ", not "space;" and ensure there is no additional invisible character there.
Save the file and restart server.

Localizable string in Foundation.framework not found

I'm getting this log warning while using my app and I'm not sure how to deal with this message:
2014-10-21 12:57:54.472 App[7067:2540152] Localizable string "(A Document Being Saved By %#)" not found in strings table "Document" of bundle CFBundle 0x12e508f60 (not loaded).
It seems, the localization file within the framework is missing, which would be really weird. Re-adding the framework didn't help.
Any hints apprechiated.
I'm getting the same message. In my case it looks like both TestFlight and Crashlytics are generating them;
[TestFlight takeOff:#"xxxxxxxxxxx"]; // Generates 2 messages
[Crashlytics startWithAPIKey:#"xxxxxxxxxxx"]; // Generates 1 message
Not causing us any trouble, so leaving them alone for now.
Update
Ok, got to the bottom of it. If you've been doing localization, chances are you probably enabled 'Localization Debugging' in your scheme (Product > Scheme > Edit Scheme in Xcode). If you're wondering why you're getting these messages from the various libraries, it's probably because you still have it enabled.
I just had this problem too.
Since turning off the warning seems like a bad idea (Feels like high risk translations will not work as intended), I tracked down what actually caused the problem.
In my case, the problem was an empty string in the Localizable.strings file. (I used a non-standard way to generate it, the default genstrings tool will not add them)
That is, in one place I had this line:
/* No comment provided by engineer. */
"" = "";
If I removed it, the warning disappeared!
Seems like there is some problem in the string table implementation if you add empty strings, that makes all string tables mess up, not only the one where the problem is...
Maybe someone will find this information useful, so I leave it here.
If you don't specify "Document" then it will look in the file Localizable.strings. Otherwise make sure you have the file Document.strings in your project. Also, "(A Document Being Saved By %#)" looks pretty weird to me. You might want to check this is really what you want as a key for a localizable string.
Here is a link that may help you understand the process
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/LoadingResources/Strings/Strings.html
From what i found in my recent project, this error occured when you have the english language (just english with no region) defined in your device.
Since one or more framework will fail to find translation strings you will have this error in your console log.
Hope that helps
Another common mistake is the forgotten ";" at the end of any line in the file, that holds your Localizable.strings. This can easily happen after massive copy and paste. Unfortunately it is not easy to locate, because the compiler does not complain with a line number or any other helpful hint. This can be very painful and tedious, when you have big localizable tables.
The result of that mistake will be, that some translations are found, others not and its hard to find the reason.
My solution to make sure, all keys are proper defined (with the ";" at the end of the line):
Open your file "Localizable.strings" in Xcode
Delete the lower half of the table (for a start)
Press COMMAND + B (build)
If you don't get an error, the problem must be in the deleted lower half. Paste it back, delete now only the lower 25 % and repeat build. Repeat the process until you can better locate the problem.
Looked all over StackOverflow looking for a solution.
And found a mistake.
I just duplicated the localization, for example:
let str = "String".localized
After that, as well:
str.localized
And after that I claim
[strings] ERROR: String not found in table Localizable of bundle
CFBundle 0x14bd01fc0

Sublime Text selection using Lua/love2d

say i have this line of code :
Object.Property.field;
Object.Property:FunctionName();
in all my sublime languages if i was to double click "Property" on either line, it would select just that word.
For some reason my lua/lua love2d syntax highlighting selects the whole line up to the ":"
How can I change this behavior, so it will only select the single word?
The reason this is occurring is because of a somewhat strange addition to the Lua Love plugin, which I assume you're using. You're using Sublime 2, so select Preferences -> Browse Packages... to open up your Packages folder, then open the Lua Love subfolder. There is a file called completions.py, which has this content:
#completions.py
import sublime
import sublime_plugin
import re
class LoveCompletions(sublime_plugin.EventListener):
ST = 3000 if sublime.version() == '' else int(sublime.version())
def on_query_completions(self, view, prefix, locations):
if self.ST < 3000 and ("lua" in view.scope_name(locations[0])):
seps = view.settings().get("word_separators")
seps = seps.replace('.', '')
view.settings().set("word_separators", seps)
Even if you don't know Python, the logic is pretty easy to follow. It sets the variable ST to Sublime's version, which is 3000+ if you're using ST3 (current build is 3061), and is 2221 (I think) for ST2. It then sets up an event listener (the process is always running in the background) checking to see if the Sublime version is less than 3000 (you're using ST2) and you have lua in your current scope (basically, your file is source.lua or source.lua.love, if you're using the plugin's language definition). If both of those are true, it removes the . character from your "word_separators" setting, which is defined in Preferences -> Settings-Default and can be overridden in Preferences -> Settings-User.
The word_separators setting controls what characters are considered to be word separators when double-clicking to select a word. Its default value is ./\\()\"'-:,.;<>~!##$%^&*|+=[]{}`~? so, for example, if you double-click on the foo part of foo-bar Sublime will only select foo, but if you double-click on the foo part of foo_bar Sublime will select the whole thing (since - is in word_separators). . is in word_separators by default, so double-clicking on foo in foo.bar will only select foo, which is expected behavior for most people, I would assume. However, this cute little plugin removes . from word_separators in Sublime Text 2, so in your case clicking on Property selects everything from the beginning of the "word" (the whitespace before Object) to the next word separator - the :, in the case of your second example.
OK, so we know what the problem is, how do we fix it? First, while you're in Packages/Lua Love, just delete completions.py altogether. There's no harm in doing so, and in fact it's actually causing harm by being there. Make sure you restart Sublime after deleting the file. Next, open Preferences -> Settings-User and add . back into the word_separators list, anywhere between the beginning and ending double-quotes. Save that file, go back to your source code, and double-clicking should once again behave normally.
Good luck!
EDIT
I submitted this pull request to delete the completions.py file from the plugin's Github repo, and it was just merged, so hopefully users in the future won't have to deal with this :)

NslocalizedString return the key instead of the value

I create tow Localizable.strings files one for english and the second for arabic :
/* The number 1 */
"LABEL_ONE" = "label number one";
I am using this code to get the string value:
[self.Lable1 setText:NSLocalizedString(#"LABEL_ONE", #"The number 1")];
but the app show "LABEL_ONE" instead of "label number one" ?
What's the problem ?
Thanks
Your string files name have to be Localizable.strings.
In addition to the top answer, the localization file has to be named Localizable.strings and not anything else.
Your code is correct, so the problem is elsewhere.
Here are some possibilities:
The Localized.strings file is not copied into the application bundle. To verify this focus on the Localized.strings file using the 'Project Navigator' and make sure your target is checked on the right pane under 'Target Membership'
There is some syntax issues within the Localized.strings file, i.e. missing ;
The code you quoted does not get executed. To verify put a breakpoint and see if it's reached or use some debug logs...
The string appears in the Localized.strings for Arabic but is missing for English.
Your problem is very simple:
The app doesn't find the file with translations.
So you must be sure that you create the localizable files with the correct name (for example en for english) and also that in your device (or simulator) you have set 1 of the languages prepared from you in these files.
Otherwise, the file is not found and is returned the key instead of the value.
try this answer it is work for me
I was having problems with this on the iOS Simulator. I ended up deleting the Localization.strings file in the simulator directory
( /Users/(me)/Library/Application Support/iPhone Simulator/5.0/Applications/(etc)/(project)/(application.app)
copied from here
https://stackoverflow.com/a/11657945
In my case cleaning the project after initially introducing i18n to it solved it.
Check whether you added any text/character by mistake after the ; in Localizable.strings file.
It doesn't show the error while running the app but XCode ignore all the key-value pair after this character, which leads to returning the key instead of values.
I put a + by mistake in string file and wasted 2 hours for this.
Make sure that the Target Membership is set to include your App and any other places you may need it. In my case, the membership was only set to the test folder
[Answer from August, 2017. Compiler may have changed]
Search for a syntax error in your .strings File
I had the following line:
"Changed your mind?" = "¿Cambiaste de opinión?";,
And somehow that made the compilation succeed, even the command plutil -lint Localizable.strings said it was okay. After I took the same comma down from each file in that line, now the compiler is able to detect there are errors.
The problem before was the compilation succeeded, but because of the comma the .strings file was actually wrong so nothing after the comma was read. I don't know if the comma has any use in .strings files.
Note:
plutil -lint Localizable.strings is used on the Terminal tu debug .strings files as Xcode cannot tell where the .strings compilation wen wrong.

Xamarin ios - import library

I need help importing a library to Xamarin. I included the library and inserted it into a new folder named BarcodeScanner, and the name of the library is libBarcodeScanner.a.
gcc_flags "-L${ProjectDir} -lBarcodeScanner -force_load ${ProjectDir}/libBarcodeScanner.a”
But it shows an error:
Error: Could not parse additional mtouch arguments: No matching quote found.
What should i do ?
Do i need to create a binding project to use a library like BarcodeScanner ?
Error: Could not parse additional mtouch arguments: No matching quote found.
That does not look like a Xamarin.iOS (mtouch) error message. Those start with a MT prefix followed by 4 numbers, e.g. MT2001. Could it be Xamarin Studio giving you this error ?
What should i do ?
Review the flags: are they identical to what's pasted above ?
No matching quote found. makes is sound there's an extra quote in there. Maybe one of the " is wrong (e.g. a autocorrection giving you a smart quote) ?
Or maybe your project directory (replaced from ${ProjectDir} contains a quote character ?
Also can you edit your question to add which version of Xamarin Studio you're using ?
Do i need to create a binding project to use a library like BarcodeScanner ?
No, but it's the preferred ways to link static libraries. Using a binding project removed the need to add Additional mtouch arguments inside every projects and every build configuration (e.g. Debug, Release...) of your applications.
I will answer my own question, maybe it will help someone. I declared in my MainController that i needed:
using MonoTouch.CoreVideo;
using MonoTouch.CoreMedia;
using MonoTouch.CoreGraphics;
using MonoTouch.CoreFoundation;
And after that i referenced only the static library with:
-gcc_flags "-L${ProjectDir} -lBarcodeScanner -force_load ${ProjectDir}/libBarcodeScanner.a"
#poupou's "maybe" was spot on, but I'll be pedantic and explain exactly.
Look closely at this line I just quoted from your original question. I've marked it down using code (four spaces prefix per line), and broke it into two lines. Nothing else has been changed. Hopefully the error should be obvious now:
- gcc_flags "-L${ProjectDir} -lBarcodeScanner
-force_load ${ProjectDir}/libBarcodeScanner.a”
Essentially, you used different types of double quotes. The first double-quote character above is Unicode 0x0022, which is the regular Quotation Mark. The second double-quote character above is Unicode 0x8221, or Right Double Quotation Mark. It might be that you had copied & pasted all or part of the line above from a web page, rather than typing it in.
For command-line processing, mixing your styles of double quotes simply won't work. You'll need to use balanced regular quotation marks, as you wrote in your own answer just now (but might not have specifically noticed?) FWIW, the right- and left- variants of the quotation mark are usually used for word processing, web pages, etc. where the style aesthetic matters.
Since you didn't use code-markup when quoting that line originally (while I noticed you did, in your recently posted answer) it looks like Stack Overflow "helpfully" tried to render the quotes as similar in style, fooling us into looking elsewhere for the problem, when it was right in front of us.
Anyway, next time you get an error about mismatched quotes, I suggest you carefully check their type. If they look the least bit different, they may not be the right kind of quotes.

Resources