I have set flash message in my controller like this
flash[:error] = t 'auth.login.empty'
My en.yml file has
en:
auth:
login:
success: "Successfully logged in"
empty: "Empty field cannot accespted"
error: "Username and password doesn't match"
All are two space indent
I am getting flash as translation missing: en.auth.login.empty
Whether i have to make some configuration changes.
I just ran into this.
A key I was setting at the top of my file was being over-written later on in the file:
# This was showing up as missing
invite:
intent_msg: "Test intent message."
# because waaaay farther down the file I had the following:
invite:
button_text: "<i class='fi-mail'></i> Send Invite"
Even though the two translations are for different keys, the second one was killing off the first one.
So now I have this:
invite:
intent_msg: "Test intent message."
button_text: "<i class='fi-mail'></i> Send Invite"
And all is well again.
Watch out for that one folks.
Your code was actually indented with tabs for the success, empty and error keys. I have fixed this up now.
Please ensure that you are really using spaces. There's no other reason that I know of as to why this would break.
Related
What I am doing:
I am using the gmail gem in a Rails 4 app to get email attachments from a specific account at regular intervals. Here is an extract from the core part (here for simplicity only considering the first email and its first attachment):
require 'gmail'
Gmail.connect(#user_email,#user_password) do |gmail|
if gmail.logged_in?
emails = gmail.inbox.emails(:from => #sender_email)
email = emails[0]
attachment = email.message.attachments[0]
File.open("~/temp.csv", 'w') do |file|
file.write(
StringIO.new(attachment.decoded.to_s[2..-2].force_encoding("ISO-8859-15").encode!('UTF-8')).read
)
end
end
end
The encoding of the attached file can vary. The particular one that I am currently having issues with is in Finnish. It contains Finnish characters and a superscripted 3 character.
This is what I expect to get when I run the above code. (This is what I get when I download the attachment manually through gmail user interface):
What the problem is:
However, I am getting the following odd results.
From cat temp.csv (Looks good to me):
With nano temp.csv (Here I have no idea what I am looking at):
This is what temp.csv looks like opened in Sublime Text (directly via winscp). First line and small parts look ok but then Chinese/Japanese characters:
This is what temp.csv looks like in Notepad (after download via winscp). Looks ok except a blank space has been inserted between each character and the new lines seems to be missing:
What I have tried:
I have without success tried:
.force_encoding(...) with all the different "ISO-8859-x" character sets
putting the force_encoding("ISO-8859-15").encode!('UTF-8') outside the .read (works but doesn't solve the problem)
encode to UTF-8 without first forcing another encoding but this leads to Encoding::UndefinedConversionError: "\xC4" from ASCII-8BIT to UTF-8
writing as binary with 'wb' and 'w+b' in the File.open() (which oddly doesn't seem to make a difference to the outcome).
searching stackoverflow and the web for other ideas.
Any ideas would be much appreciated!
Not beautiful, but it will work for me now.
After re-encoding, I convert the string to a char array, then remove the chars I do not want and then join the remaining array elements to form a string.
decoded_att = attachment.decoded
data = decoded_att.encode("UTF-8", "ISO-8859-1", invalid: :replace, undef: :replace).gsub("\r\n", "\n")
data_as_array = data.chars
data_as_array = data_as_array.delete_if {|i| i == "\u0000" || i == "ÿ" || i == "þ"}
data = data_as_array.join('').to_s
File.write("~/temp.csv", data.to_s)
This will work for me now. However, I have no idea how these characters have ended up in the attachment ("ÿ" and "þ" in the start of the document and "\u0000" between all remaining characters).
It seems like you need to do attachment.body.decoded instead of attachment.decoded
i am using calabash to do testing on a iOS native app. calabash takes a screenshot and names it screenshot_0 on scenario failure and saves it in my project directory.
i want to know how i can change the path of the screenshot and how i can change the name of the file.
i used the following:
dir_path = "/Users/bmw/Desktop/Calabash/screenshots "
unless Dir.exist?(dir_path)
Dir.mkdir(dir_path,0777)
puts "=========Directory is created at #{dir_path}"
else
puts "=========Directory already exists at #{dir_path}"
end
#Run after each scenario
After do |scenario|
#Check, scenario is failed?
if(scenario.failed?)
time = Time.now.strftime('%Y_%m_%d_%Y_%H_%M_%S_')
name_of_scenario = time + scenario.name.gsub(/\s+/, "_").gsub("/","_")
puts "Name of snapshot is #{name_of_scenario}"
file_path = File.expand_path(dir_path)+'/'+name_of_scenario +'.png'
page.driver.simulator.save_screenshot file_path
puts "Snapshot is taken"
puts "#===========================================================#"
puts "Scenario:: #{scenario.name}"
puts "#===========================================================#"
end
end
i had seen page.driver.browser,simulator.save_screenshot somewhere... and replaced browser with simulator and that did not work...
is there any way to change location where ios sim saves simulator without touching failure_helpers?
Calabash exposes and environment variable named SCREENSHOT_PATH you can use to set the path where to save the screenshots.
As for the file name, you might want to try and use the screenshot API. Reading your comment you seem to have tried it already, but I think you might not have used the proper signature.
Looking at the source for screenshot we see that it's defined like this:
def screenshot(options={:prefix => nil, :name => nil})
...
As you can see it's expecting a map, so what you should try is
screenshot({:name => name_of_scenario })
Also note that the documentation says that the use of screenshot_embed is preferred to screenshot.
On some app' setup
Everything works fine within the email, in the body
There is a problem with the subject of this email, containing special characters,
which would output the following for exemple in the mailboxes :
a été validée !
Searching around, I ended up with the following that works :
s = ("...a été validée !...").encode!("ISO-8859-15")
m = mail(to: email, subject: s)
But I guess that it is just a setup thing that would make everything works fine
Has anyone any experience about it ?
Can you try this in your application.rb?
config.action_mailer.default_charset = "iso-8859-15"
I'm using the default (utf-8) and accents work just fine, so you may want to see if there's something else that's botching up your data.
UPDATE: since this is only an issue with your subject, I think you may be able to fix this by adding this to the top of your source file that contains that subject line:
# encoding: UTF-8
Please try that out and let me know.
I am localizing an app into German using Localizable.string.
All well until I need to use a ü or ß type letter in the localized string.
I get an error when building.
de.lproj/Localizable.strings:0: error: validation failed: The data couldn’t be read because it has been corrupted.
Example;
"Simple introductions and alphabet" = "Einfache Begrüßungen und das Aphabet";
Anyone out there with a solution?
Thanks
In my case neither of the other answers fixed my problem. After spending some time with searching for help, I somehow noticed I forgot a semicolon on the end of a line.
Admittedly this is a really basic error on my behalf, but the compiler could have told me my mistake instead of:
Validation failed: The data couldn’t be read because it has been corrupted.
So remember that strings table files have to be in the format
"Key" = "Localized Value goes here";
After conversation in comments the problem was solved.
If you will have similar problem then first of all you should check text encoding of file where error occurred. You can find current text encoding and change it in Xcode:
Open file in Xcode.
Press ⌥⌘1 (thanks #Jano)
Find field Text Encoding
Set it to Unicode (UTF-8)
Try to rebuild the project
Does anyone know how to make assert_select not output all those nasty html warnings during a rake test? You know, like this stuff:
.ignoring attempt to close body with div
opened at byte 1036, line 5
closed at byte 5342, line 42
attributes at open: {"class"=>"inner02"}
text around open: "</script>\r\t</head>\r\t<body class=\"inner02"
text around close: "\t</div>\r\t\t\t</div>\r\t\t</div>\r\t</body>\r</ht"
Thanks
It's rather that your code is generating invalid HTML. I suggest running it through a validator and fixing all the validation errors.
You can find out which test ran into the problem by using the TESTOPTS v flag:
(bundle exec) rake test TESTOPTS="-v"
This will give:
test: Request the homepage should have a node list. (PresentControllerTest): .
test: Request the homepage should have the correct title. (PresentControllerTest): ignoring attempt to close div with body
opened at byte 4378, line 89
closed at byte 17745, line 393
attributes at open: {"class"=>"colleft"}
text around open: "class=\"colmid\"> \n\t\t\t<div class=\"colleft\""
text around close: "x2.js\" ></script>\n </body>\n</html>\n\n"
ignoring attempt to close div with html
opened at byte 4378, line 89
closed at byte 17753, line 394
attributes at open: {"class"=>"colleft"}
text around open: "class=\"colmid\"> \n\t\t\t<div class=\"colleft\""
text around close: "</script>\n </body>\n</html>\n\n"
.
test: Request the homepage should not set the flash. (PresentControllerTest): .
test: Request the homepage should respond with 200. (PresentControllerTest): .
Rails's HTML scanner expects XHTML, if you're using HTML4 where tags don't have explicit closing tags, you may get this warning... doesn't look like solved issue
http://dev.rubyonrails.org/ticket/1937
http://gilesbowkett.blogspot.com/2009/10/ignoring-attempt-to-close-foo-with-bar.html
What I'd want is to know where the warning is coming from. The fact it doesn't specify the test or the controller/action which generates the invalid HTML is the big problem for me.
I had some problems after an update to rails 3.0.9 and HAML 3.1.2
What I did was silence those ugly outputs with the following code in *test_helper.rb*
# Wrap up the method assert_select because after updating to Rails 3.0.9 and HAML 3.1.2,
# I don't know why but it was raising warnings like this:
# ignoring attempt to close section with body
# opened at byte 6157, line 128
# closed at byte 16614, line 391
# attributes at open: {"class"=>"left-column"}
# text around open: "->\n\n\n</span>\n</div>\n<section class='left"
# text around close: "'1'>\n</noscript>\n</body>\n</html>\n"
# But the HTML seems to be valid (in this aspects) using a HTML validator.
ActionDispatch::Assertions::SelectorAssertions.class_eval do
alias_method :assert_select_original, :assert_select
def assert_select(*args, &block)
original_verbosity = $-v # store original output value
$-v = nil # set to nil
assert_select_original(*args, &block)
$-v = original_verbosity # and restore after execute assert_select
end
end
Anyway, I don't recommend using a solution like this. Use only if you are in hurry, and give it a good comment to explain other developers why is that estrange piece of code there.
For me, the cause was valid but poorly formed HAML.
This is what I had:
%ul
%li
= link_to "Help", help_url
- if current_user
%li
= link_to "Users", users_url
= link_to "Logout", logout_url
- else
= link_to "Login", login_url
This is what is correct for what I'd wanted to do:
%ul
%li
= link_to "Help", help_url
%li
- if current_user
= link_to "Users", users_url
= link_to "Logout", logout_url
- else
= link_to "Login", login_url
The best way to track this down is to look very carefully at the "text around open" and "text around close" and try to track down where in your template the open occurs.
Even if you do rake test TESTOPTS="-v" and the error appears to be coming from your view templates, DON'T forget to check the application layout html. This happened to me and it took a few minutes longer than I'd like to admit going back and forth between a couple index.html.erb files before I finally figured it out. Same goes for any rendered partials.