[Scummvm-devel] Including README translations

[Filippos Karapetis]

>
> > That's odd, was the version you mentioned the daily version? What error
> > are
> > you getting?
>
> Yes, it was the daily build by buildbot from the mater branch. It said
> something in the error message about the kernel.


Can you be more specific? What is the error message you're getting?

No, no, stop! :) I didn't mean that you should start working on a DOS port
> now. I only wanted to use it as an example to show my interest in supporting
> OS'es that are explained dead by marketing people.


Well, DOS, Windows 3.1/95/98/ME (along with other OSes, like OS/2) are
considered "dead"
as in, the companies that made them stopped supporting them, and drivers are
no longer developed
for them. For example, both ATI and NVIDIA stopped supporting Windows
95/98/ME in 2005.

That said, if we do have people interested in maintaining support for them,
that's great. However,
maintaining support for them can be an additional burden, that's all. For
example, Microsoft has
stopped supporting Windows 98 in Visual Studio 2010.

Well, I didn't mean to imply that A LOT OF people do use these systems, but
> I did imply some few people still DO - for whatever reason. I don't want to
> get into deep political and ethic discussion now, but I'd like to say that
> most of the people on planet earth live in deep poverty. They may be
> depending on such an old OS once they afford to get an old computer. I
> simply think we should try having software that works for ALL people as long
> as it is possible and doesn't cause too much work.
>

The reasons why people are using Windows 98 can be multiple, but the fact
still remains: it's a long
dead OS that does not support Unicode natively.
A good discussion concerning Windows 9x has been made in portableapps, and
it's worth reading.
Check:
http://portableapps.com/node/17291

If we can avoid it, we can maintain Windows 9x compatibility, but we should
not convert documents
and data files to ANSI just to support a marginal number of users that may
want to read non-English
documents in Notepad under Windows 9x. We should be moving forward as a
project. Unicode has
been around for a long time, and it has been proven to be a very good
standard in internationalization.
So, IMHO, it's wrong to drop Unicode for very few people who don't want to
use Unicode-aware text
editors in legacy systems.


> My reasons for re-encode the readme translations to ANSI are simple: For
> me, ANSI and UTF-8 were on the same level as I wrote my previous emails. So
> for the cause of using it in Windows, both could be used in my opinion.
> Since the legacy Windowses have problems with UTF-8, I thought we could
> convert it to ANSI all the way. The readme translations don't contain any
> additional special letters. For example, if we were using Cyrillic and
> Polish letters in the German translation file, then I would have seen the
> need to use UTF-8. But no I see a slightly advantage: When opening the
> German readme on a Russian Windows for example, it will show wrong
> characters with ANSI but the right ones with UTF-8.
>

ANSI is really not portable, for the reasons you explained. So moving back
to ANSI is a disadvantage
in my eyes, which is a great step backwards from the portability that
Unicode provides.


>   Anyway, I did check the file behaviour under Windows ME and I saw that
> the big readme was opened automatically in Wordpad using the right encoding.
> But because our translations are just an excerpt of it, they will always
> open there in the small standard editor. So maybe a conversion should be
> done only for Win 95 etc. if those files are under the size for being opened
> with WordPad.
>

What is the small standard editor here? Are you referring to Notepad?


> As for now, I think we should add the UTF-8 header by default for the
> "normal" (not-legacy) Windows version and deal with the older versions
> later.


Are you referring to the BOM byte sequence? Theoretically we could add it,
but that's generally not
recommended, as it defeats the whole purpose of Unicode (check the Wikipedia
article here:
http://en.wikipedia.org/wiki/Byte_order_mark). And since you said that
you're not having problems
with Notepad, perhaps the editor you're using is problematic?

>  I just said it does? UTF8 IS Unicode, btw.
>
> Maybe we are talking about two different Unicodes there: When writing a
> file in Notepad and trying to save it, then you get to select the encoding.
> You can select there ANSI, UTF-8, Unicode, Unicode Big Endian. I guess the
> Unicode there means Unicode little Endian as I get there a text where each
> letter consists of two bytes. In UTF-8 to the contrary, only the "special
> letters" consist of two bytes if I remember correctly.


Indeed, there are a lot of different flavors of Unicode. UTF8 is one of them
(the most widely used one).
A lot of Windows programs use UTF16, but they can understand UTF8 correctly.

Anyway, to sum things up: we got the following options currently:
- Leave things as they are and keep using UTF8 encoding without a BOM
character (which is the
"correct" way)
- Add a BOM character for broken editors and older Windows versions (which
is wrong, but
legacy applications don't have issues with it)
- Convert everything to ANSI (bad idea, as it's non-portable and obsolete
for internationalized content)
- Keep both a Unicode and an ANSI version (which can be confusing for some
users)

Thoughts?

Regards
Filippos

-- 
"Experience is the name every one gives to their mistakes" - Oscar Wilde
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20110625/5b83dabe/attachment.html>