Fix the Windows build on Japanese systems. #1182

Merged
merged 1 commit into from Aug 26, 2012

Projects

None yet

2 participants

@zewt
Contributor
zewt commented Jul 19, 2012

guilib/LocalizedStrings.cpp was in ISO-8859-1. MSVC only autodetects
UTF-8; if a file isn't UTF-8, it assumes it's in the ANSI codepage, which
depends on the build system. That means this file was detected correctly
on US English systems (whose encoding is very similar to 8859-1), but
incorrectly on others.

This caused the compiler to choke, since it misinterprets the non-ASCII
characters as SJIS, causing the quotes after the strings to be mojibake'd
away and giving unterminated string literal errors.

Convert this file to UTF-8, so it's autodetected in any system codepage.

This needs to be tested in other build environments. I don't expect
problems with gcc; it builds UTF-8 sources without trouble.

@zewt zewt Fix the Windows build on Japanese systems.
guilib/LocalizedStrings.cpp was in ISO-8859-1.  MSVC only autodetects
UTF-8; if a file isn't UTF-8, it assumes it's in the ANSI codepage, which
depends on the build system.  That means this file was detected correctly
on US English systems (whose encoding is very similar to 8859-1), but
incorrectly on others.

This caused the compiler to choke, since it misinterprets the non-ASCII
characters as SJIS, causing the quotes after the strings to be mojibake'd
away and giving unterminated string literal errors.

Convert this file to UTF-8, so it's autodetected in any system codepage.

This needs to be tested in other build environments.  I don't expect
problems with gcc; it builds UTF-8 sources without trouble.
5a48630
@ghost
ghost commented Jul 20, 2012

This will break. We need those chars in iso and not utf for reasons I cannot recall right now.

Contributor
zewt commented Jul 20, 2012

Please try to recall it. Currently, it is broken.

@ghost
ghost commented Jul 20, 2012

I will once on something a bit more practical than my phone.

Contributor
zewt commented Jul 20, 2012

Could this be a legacy from older versions of VC?

VC2008 (I believe) and earlier always treated source files as if they're in the ANSI codepage, so putting UTF-8 in source would cause errors in certain codepages. This might be a workaround for that. (It'd only be a partial workaround, probably for a particular user's codepage, since whether that worked or not would depend on the local codepage.) VC2010 autodetects UTF-8, which makes it easier to avoid problems.

Member

Heh, no idea :)

On Sat, Jul 21, 2012 at 10:15 AM, Arne Morten Kvarving <
reply@reply.github.com

wrote:

@jmarshallnz remember what
http://xbmc.cvs.sf.net/viewvc/xbmc/XBMC/guilib/LocalizeStrings.cpp?r1=1.74&r2=1.75was about? :)


Reply to this email directly or view it on GitHub:
#1182 (comment)

Contributor
zewt commented Jul 20, 2012

The date on that supports my guess, anyway...

If you're really worried, it could just be sidestepped entirely with hex escapes, but I'd see if it's really needed first.

Member

@alanwww1 your comments?

Contributor
zewt commented Aug 18, 2012

It would be nice to get this applied; it's a bit of a pain. This just looks like a workaround for old versions of VS (which I don't think XBMC even has project files for anymore).

@jmarshallnz jmarshallnz was assigned Aug 26, 2012
Member

Nothing should break as far as I can tell, so pulling. If it breaks, at least it builds on Japanese systems, so we have more people to help fix it :)

@jmarshallnz jmarshallnz merged commit 8188e27 into xbmc:master Aug 26, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment