Gettextization casualty - swedish

[isaac]

I did a newline (hit enter) after "now". It will not be displayed unless I put a \n there, right? I saw some thread on this, but I just want this behaviour confirmed.

Yes, it will be a single line, you need the \n to force a new line.

[tephlon]

Oh, extremely consistent

Great

EDIT:Perhaps we should move the discussion on individual translation to the Översättning till svenska thread.

Yes, I will do that in the future. At this moment I am/was just interested in the overall consistency in the current translation Seems I will have to check that too. Ooof

Thanks for the confirmation, isaac.

Cheers

[sanna]

At this moment I am/was just interested in the overall consistency in the current translation

Speaking of consistency, I did a rerun of the manual in swedish, in order to get it in line with the general translation. I sent it to KK_r for his comments, but after I got them I never seem to have gotten around to publishing it.
Well here it is:

[tephlon]

Maybe I should start a new thread on this, but well...

I've gotten into a problem here. The sv.po which I have started translating in comes from this thread, and is also identical to the one in the CVS tree. After unfuzzing about half of the fuzzy translations - 400 to go - I decided to do the make update-po and make install to see how it looked. Everything seemed to compile just fine, but then I saw that I had over 1000 fuzzy strings! It went from 400 to 1000! Whoops! Today I've tried to see where this comes from and I think I've found it.

Almost every string in "my" sv.po ends with a space, like in "Heir to the Throne ". Now, comparing this with the wesnoth.pot files in the CVS tree and in the version 0.8.3 source, a whole lot of strings (maybe all) which previously ended with a space now ends without a space, like in "Heir to the Throne". That makes both poedit and kbabel to think that about a 1000 strings are obsolete and about 1000 strings are to be updated when I sync with the pot file. I guess this is also what happened in the compilation.

Is there a simple solution to this? Just using sed to change ' "' to '"' won't do, since I would destroy strings that goes over several lines where every line is "terminated" with a ", like in sentences.

Cheers

[sanna]

Is there a simple solution to this? Just using sed to change ' "' to '"' won't do, since I would destroy strings that goes over several lines where every line is "terminated" with a ", like in sentences.

Would replacing<space>"<newline>msgstr with "<newline>msgstr work? When I did that on my local (outdated, I'm sure) version of sv.po it replaced 968 such strings. Seems to match your new fuzzballs quite well.

[tephlon]

How did you do that? I can't figure out how I can make sed match consecutive lines...

[sanna]

How did you do that? I can't figure out how I can make sed match consecutive lines...

Aah, I'm on mac, using BBEdit, with in-built grep find and replace. Wouldn't know how to use sed. But if you post the current sv.po (or should that be the pre-last-compile? sv.po), I can run that replace for you.

[tephlon]

Yes, please

I'll try to do this myself in the future, but I'm a bit impatient

Here it is!

[cedric]

tephlon,

Now, comparing this with the wesnoth.pot files in the CVS tree and in the version 0.8.3 source, a whole lot of strings (maybe all) which previously ended with a space now ends without a space, like in "Heir to the Throne".

I'm quite confused as to what may have added you all these spaces (maybe some editor, blindingly trying to be too smart?). But what I'm sure of, is that there has never been all these spaces in the original strings.

If you want, I can replace in CVS all occurences of ' "\nmsgstr' with '"\nmsgstr' for you. Of course, it will be automatic, and it may result in a few false positives, but in the end it should be better. Just tell me.

EDIT: ok, sanna did it already. But my advice would be to try to identify the cause of this, to be sure it won't happen anymore.
--
Cedric

[sanna]

OK, have fun

[tephlon]

Wohoo! Thanks a bunch, sanna!

Cedric: Thanks for the offer, but sanna was quicker

Hmm, I have to see what caused this...

Well, KBabel can use something called "Clever editing", where it tries to add spaces at approriate places, exchanging " to \" and so on. But that doesn't change the msgstr.

Aha! The "syntactically correct" sv.po file that I downloaded from this thread does contain these too, so I don't think it was KBabel's fault.

Well, cheers

[sanna]

BTW: there are quite a lot of msgid ""<newline>" too, do you want me to strip them out to?

[cedric]

BTW: there are quite a lot of msgid ""<newline>" too, do you want me to strip them out to?

If you're speaking about things like the following, then it's ok.

Code: Select all

msgid ""
"Swordsmen are the core of the human armies. These young soldiers are given "
"basic training and put in the front lines to do the bulk of the fighting."

msgmerge does this whenever the text is too long to fit on the msgid line. (standard 80 characters line, see also its --width option)

--
Cedric

[sanna]

If you're speaking about things like the following, then it's ok.

Code: Select all

msgid ""
"Swordsmen are the core of the human armies. These young soldiers are given "
"basic training and put in the front lines to do the bulk of the fighting."

Yep, that's what I'm talking about. Is it also OK not to have them?; i.e., is what is actually used as id the merged lines stripped from all citation marks, (that's how I've understood it)

[cedric]

Is it also OK not to have them?; i.e., is what is actually used as id the merged lines stripped from all citation marks, (that's how I've understood it)

Yes, the lines are just merged. Basically, it doesn't matter. You can reformat these lines if you really want, but most certainly they will reappear at the next msgmerge (unless you use the --width option to specify a different max line length). So, why bother?

You may wonder why this arbitrary split. Well, a lot of weird people just love working in a 80 characters wide terminal and hate auto-wrapping.It's that simple.
--
Cedric