I hope I have already satisfied the first condition as I have tried to translate all the aplications. But I have to admit that I have never tried other database then MySQL.
Fresh installations using the setup seems to be OK. But I would need a help from somebody who uses 1.2 version with existing ISO-8859-2 encoding. It would be nice to test the upgrade using the backup and restore tools. I will try to search Czech forums to get someone.
I also realized that there is only one encoding available for CSV imports when there is only one language installed in eGroupWare. So if I select for example Czech language in UTF-8 encoding during the setup, I will be able to import CSV files in UTF-8 encoding only.
Changing the translation will probably always cause some pain. But I beleieve there will be more and more web apps using UTF-8 encoding so it might be better to do it now than later with even more pain. For anybody who had to run several applications with different encodings on the same Apache server it would be relief to have one encoding for all of them.
Best regards
Michal
Oscar Manuel Gómez Senovilla wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MichalS escribió:
> Hello!
>
> At the end of February I have started to work from scratch on the new Czech
> translation, because the former one was far from complete. I based my
> translation on English files, but I was not sure in many cases so I also
> used Slovak and Spanish files a lot. Since I did the whole work from
> beginning I also decided to change the encoding. Why? Because IMHO UTF-8 is
> the future and everything else is the past. Czechs used ISO-8859-2 mainly on
> UNIX based systems and CP1250 on Windows systems. So we didn't have unified
> encoding anyway. I believe, that somebody who needs other encoding can
> convert those language files easily.
I'm not against switching charsets, but I see two major drawbacks:
1) It would require by the translator changing the charset to take care
of *all* existing phpgw_XX.lang files, so there's nothing left alone.
2) Make sure the new charset (usually utf-8) is common and not a problem
on the db side. This means that some db engines supported by egw could
require an extra tunning/tweaking to support utf-8. And what's worse,
existing installations could stop working successfully.
There's an extra issue that I don't know how it's built, and it's the
initial selection list that you can see in /setup when choosing the
charset for the language right before installing all apps.
Maybe in a future all translations will switch to utf-8, but I'd just
like to know any other reasons for a language not to switch (now or in
the future) to utf-8.
Regards.
- --
|----------------------------------------------------------------------|
| http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 |
| Oscar Manuel Gómez Senovilla - omgsATescomposlinux.org |
| GPG Key at http://pgp.escomposlinux.org |
|----------------------------------------------------------------------|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/ _______________________________________________
eGroupWare-translation mailing list
eGroupWare-translation@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-translation
