Override file message is not totally translated

[humitos]

Steps to reproduce it:

1. Open InfoSlicer
2. Edit an article
3. Export your work
4. Export your work again

Issue:

You will see that the message is partially translated (see screenshot)

Behavior:

Show the message totally translated.

Environment:

• git version of info slicer

[humitos]

There is a problem with multiple lines strings and gettext:

•  http://savannah.gnu.org/bugs/?35109

[walter]

I split lines all the time (for help strings in Turtle Art) and have never encountered this bug, but then again, I am using UTF-8. So maybe it is as simple as telling infosclicer about UTF-8?

[cjl]

I believe our L10n infrastructure is dependent on UTF-8 encoding in order to capture the full array of characters we may need to represent in the many languages we work with.

[walter]

I used a slightly different approach that seems to fix the problem:

See attached patch.

[humitos]

Did you test your patch?

When I run "genpot" with your patch applied I get this error:

xol.py:62: warning: internationalized messages should not contain the `\r' escape sequence

I go to the .pot file and effectively I see the same behavior that this ticket mentions.

The solution is re-encode the file as I did. We have to change the end-of-line style:

•  https://en.wikipedia.org/wiki/Newline

• This is wrong for us (DOS format)

  $ file xol.py
  xol.py: Python script, ASCII text executable, with CRLF line terminators
  

• This is right

  $ file xol.py
  xol.py: Python script, ASCII text executable
  

How to change this:

vim xol.py
:set fileformat=unix
:wq

That command will modify all the lines of the file to change the end-of-line.

We don't want to deal with DOS end-of-line style, it's from 70's :)

[walter]

I didn't run genpot, I ran build and got no warnings. And when I ran the activity, I got the proper strings in Spanish.

But I see that the POT file is wrong. I don't understand why I never encounter this problem with TurtleArt.

[humitos]

TurtleArt has no "CRLF line terminators" in any of its .py files. Take a look at the log attached. That is why you didn't notice this problem.

[walter]

Let's solve the problem by getting side of the CRLFs.

[humitos]

Pushed:

•  http://git.sugarlabs.org/infoslicer/mainline/commit/496dc1a37ffabc3000b63767c72ae81507106921

This will be available in version 15.