I was working with xliff file without any issues translating one of my apps to spanish. Now all of sudden Xcode's "Export for Localization" feature has stopped working. If I go to Editor->Export for Localization nothing happens, I am asked where I want to save the xliff file but when I select a location nothing happens. If I try to do the export again I get an error message saying: "There is a localization operation in progress".
I've tried restarting Xcode and my computer to no avail. Has anybody else encountered this issue?
I just ran into the same problem! In my case, it was because the file Localizable.strings contained strings with quotes in them.
E.g. your file may contain something like this line:
"This is a “test”." = "Das ist ein "Test".";
Xcode's code highlighting will show that something is wrong:
The original English sentence works because the quotes in the string are smart quotes, but the quotes in the German translation interrupt the string and make it invalid.
This problem could be in any of your strings files, like Localizable.strings, InfoPlist.strings etc. To find lines like this in a large strings file, you can search by Regular Expression with this expression:
(".*){5}
This will find all lines that have more than 4 quotation marks. As I mentioned, smart (curly) quotes are accepted. You can use normal quotes by escaping them - so this would also be acceptable:
"This is a “test”." = "Das ist ein \"Test\".";
Related
Expression Activity type 'VisualBasicValue`1' requires compilation in order to run. Please ensure that the workflow has been compiled.
how to solve this error
This can happen when a string with quotes is copied from a RTF formatted app, such as Microsoft Word. The " quotation character is not the code version. Try deleting the current assignment in the write cell activity and type manually so that the quotes (") are of the right type. Notice the slanted quotes vs. the straight quotes in the two examples below:
“This is a quote from an RTF app”
"This is a quote from a code editor"
I've search both SO and Rstudio's community pages and failed to find aquestion, much less and answer to this annoyance I have experienced with Rstudio. (The Rstudio help pages won't let me post a second question within 12 hours of my first, which was explained as a bug.)
If I type:
(test)
... and then realize that test should be quoted, then putting the cursor at the end to test and entering a double-quote will give me two double-quotes "". It will not do this if I first enter a quote between ( and t and then it will also not give me doubling of the double-quote character at the end of `test. Why should it matter whether I first correct my error at the end of the symbol or at the beginning? Is there anything I can do to modify this quirk> It seems that a syntax aware console editor out to be able to tell when a doubling of quotes does not make sense. It's obviously making that "decision" when the quotes are entered between an open-paren and a character. Why not suppress the unhelpful behavior when it is between a character and a close-paren?
In using the Page Object gem, I'm trying to pull text from a page to verify error messages. One of these error messages contains double-quotes, but when the page object pulls the text from the page, it pulls some other characters.
expected ["Please select a category other than the Default â?oEMSâ?? before saving."]
to include "Please select a category other than the Default \"EMS\" before saving."
(RSpec::Expectations::ExpectationNotMetError)
I'm not quite sure how to escape these - I'm not sure where I could use Regexs and be able to escape these odd characters.
Honestly you are over complicating your validation.
I would recommend simplifying what you are trying to do, start by asking yourself: Is the part in quotes a critical part of your validation?
If it is, isolate it by doing a String.contains("EMS")
If it is not, then you are probably doing too much work, only check for exactly what you need in validation:
String.beginsWith("Please select a category other than the Default")
With respect to the actual issue you are having, on a technical level you have an encoding issue. Encode your result string with utf-8 before you pass it to your validation and you will be fine.
Good luck
It's pretty likely that somewhere along the line encoded the string improperly. (A tipoff is the accented characters followed by ?.) It seems pretty likely that the quotes were converted to "smart quotes" somewhere. This table compares Window-1252 to UTF-8:
Code Point Characters UTF-8 Bytes
Unicode Windows
1252 Expected Actual
------ ---- - --- -----------
U+201C 0x93 “ “ %E2 %80 %9C
U+201D 0x94 ” †%E2 %80 %9D
What you'll want to do is spot check various places in the code to find the first place the string is encoded in something other than UTF-8:
puts error_str.encoding
(For clarity, error_str is the variable that holds the string you are testing. I'm using puts, but you might want have another way to log diagnostic messages.)
Once you find the string that's not encoded UTF-8, you can convert it:
error_str.encode('UTF-8')
Or, if the string is hardcoded somewhere, just replace the string.
For more debugging advice, see: 3 Steps to Fix Encoding Problems in Ruby and How to Get From They’re to They’re.
In my terminal, when I'm typing over the end of a line, rather than start a new line, my new characters overwrite the beginning of the same line.
I have seen many StackOverflow questions on this topic, but none of them have helped me. Most have something to do with improperly bracketed colors, but as far as I can tell, my PS1 looks fine.
Here it is below, generated using bash -x:
PS1='\[\033[01;32m\]\w \[\033[1;36m\]☔︎ \[\033[00m\] '
Yes, that is in fact an umbrella with rain; I have my Bash prompt update with the weather using a script I wrote.
EDIT:
My BashWeather script actually can put any one of a few weather characters, so it would be great if we could solve for all of these, or come up with some other solution:
☂☃☽☀︎☔︎
If the umbrella with rain is particularly problematic, I can change that to the regular umbrella without issue.
The symbol being printed ☔︎ consists of two Unicode codepoints: U+2614 (UMBRELLA WITH RAIN DROPS) and U+FE0E (VARIATION SELECTOR-15). The second of these is a zero-length qualifier, which is intended to enforce "text style", as opposed to "emoji style", on the preceding symbol. If you're viewing this with a font can distinguish the two styles, the following might be the emoji version: ☔︉ Otherwise, you can see a table of text and emoji variants in Working Group document N4182 (the umbrella is near the top of page 3).
In theory, U+FE0E should be recognized as a zero-length codepoint, like any other combining character. However, it will not hurt to surround the variant selector in PS1 with the "non-printing" escape sequence \[…\].
It's a bit awkward to paste an isolated variant selector directly into a file, so I'd recommend using bash's unicode-escape feature:
WEATHERCHAR=$'\u2614\[\ufe0e\]'
#...
PS1=...${WEATHERCHAR}...
Note that \[ and \] are interpreted before parameter expansion, so WEATHERCHAR as defined above cannot be dynamically inserted into the prompt. An alternative would be to make the dynamically-inserted character just the $'\u2614' umbrella (or whatever), and insert the $'\[\ufe0e\]' in the prompt template along with the terminal color codes, etc.
Of course, it is entirely possible that the variant indicator isn't needed at all. It certainly makes no useful difference on my Ubuntu system, where the terminal font I use (Deja Vu Sans Mono) renders both variants with a box around the umbrella, which is simply distracting, while the fonts used in my browser seem to render the umbrella identically with and without variants. But YMMV.
This almost works for me, so should probably not be considered a complete solution. This is a stripped down prompt that consists of only an umbrella and a space:
PS1='\342\230\[\224\357\270\] '
I use the octal escapes for the UTF-8 encoding of the umbrella character, putting the last three bytes inside \[...\] so that bash doesn't think they take up space on the screen. I initially put the last four bytes in, but at least in my terminal, there is a display error where the umbrella is followed by an extra character (the question-mark-in-a-diamond glyph for missing characters), so the umbrella really does occupy two spaces.
This could be an issue with bash and 5-byte UTF-8 sequences; using a character with a 4-byte UTF-encoding poses no problem:
# U+10400 DESERET CAPITAL LETTER LONG I
# (looks like a lowercase delta)
PS1='\360\220\220\200 '
I wrote an alternative fonction to open AutoCAD drawings. However, AutoCAD made it really hard to change how a document is opened when it is ran from Windows Explorer (double click the file with file association). The only method I found is to change a registry key which is "OpenDdeExec". There is a supplied argument (%1) that gives me a unescaped path to the file to open.
I need to ignore the escaping in path or replace the backslashes with double backslashes before it gets parsed as being special characters. In C#, you could do something like string s = #"I\Like random\backslashes"; and backslashes would be taken as the actualy backslashe character. In lisp, the only equivalence I found is quote which has a weird behavior (since it's normal use isn't exactly what I'm trying to acheive).
If I write something like (quote (I\Like random\backslashes)), the outcome will be (I\\Like random\\backslashes) which is ALMOST what I need. However, I have to get rid of the parenthesis. Any idea how I can acheive this?
Note: Doing this (quote I\Like random\backslashes) will break due to the space. It would, however, work on (quote I\Like\backslashes). This would output I\\Like\\backslashes just like I want.
This is the current OpenDdeExec with the described issue:
(OPENFROMSHELL (QUOTE (%1)))
This is unfortunately not possible with AutoCAD's limited LISP.