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.
The patch I have posted few days ago is obselete now. I have already translated missing modules (setup, jinn, workflow, message) so I will post another one soon (I would like to make final revision first). My translation surely won't be perfect, because sometimes it is very difficult to understand what the author meant and I am not experienced eGW user yet. But I believe, it will be much better then the previous one and I would like to improve it step by step in the future.
Best regards
Michal
Summary: 709 - Czech language files
New Czech language files for upcoming 1.4 version of eGroupWare. Encoding UTF-8. All main modules are translated except Setup. I will try to translate the rest and correct as many errors as possible till final 1.4 release.
> Comment by Oscar Manuel GĂłmez Senovilla at 2007/05/20 12:01:
I'm puzzled for this. There is previous work from other czech translators that would be overwritten with this. I don't know at this very moment what's the most widely charset used for czech, so please read http://www.egroupware.org/index.php?page_name=wiki&wikipage=Translation+manager+and+Team and suscribe to the mailing list. Once there, expose your reasons to change the current charset from iso-8859-2 to utf-8, and if there's agreement (which previously needs to have updated *all* existing czech files), I'll switch.
Re: new Czech translation for eGW
by Oscar Manuel Gómez Senovilla
::
Rate this Message:
> 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
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
Re: new Czech translation for eGW
by Oscar Manuel Gómez Senovilla
::
Rate this Message:
>
> 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've just replied privately to a Michal's private mail, and I'd like to
reproduce it here (ccing Ralf):
"I got a reply from Ralf about this and he warned about possible data
corruption. Also, there are users that seem to have strong reasons to
not switch the charset (beyond my knowledge). With this in mind, I don't
feel like changing the charset at this very moment, so please try to
provide a translation using iso (remember to change the "charset" entity
in phpgwapi/setup/phpgw_cs.lang).
And please remember: at least since egw 1.2, the fact that your language
files are iso doesn't mean you can't use utf-8. That's only the encoding
used in the files themselves and (I think) the default suggestion for
your language. Spanish default for lang files is iso-8859-1, but I try
to use utf-8 in the installation."
The possible data corruption comes mostly (all?) because a bug in old
1.0 installations. Surely in the next future release after 1.4 this can
be forced to be changed to utf-8, maybe avoiding any kind of
responsability for still keeping old and unmaintained 1.0.x releases.
This means please keep using your current charset for contributing, and
if you want, and find that you miss some functionality, then test utf-8
and report about it (if it's a bug).
What I consider the most important of all is that if I take this
decision alone this can affect the whole application behaviour and data,
and this is beyond my role, unless the core developers agree with it.
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
OK, I gave up my fight for UTF-8 encoding... I converted all files with the iconv utility, changed the charset entitiy to iso-8859-2 in both Setup and API language files and tested the result with the latest trunk version. Everything seems to be OK. I have uploaded the language pack to tracking system few minutes ago.
Best regards
Michal
Oscar Manuel Gómez Senovilla wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MichalS escribió:
>
> 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've just replied privately to a Michal's private mail, and I'd like to
reproduce it here (ccing Ralf):
"I got a reply from Ralf about this and he warned about possible data
corruption. Also, there are users that seem to have strong reasons to
not switch the charset (beyond my knowledge). With this in mind, I don't
feel like changing the charset at this very moment, so please try to
provide a translation using iso (remember to change the "charset" entity
in phpgwapi/setup/phpgw_cs.lang).
And please remember: at least since egw 1.2, the fact that your language
files are iso doesn't mean you can't use utf-8. That's only the encoding
used in the files themselves and (I think) the default suggestion for
your language. Spanish default for lang files is iso-8859-1, but I try
to use utf-8 in the installation."
The possible data corruption comes mostly (all?) because a bug in old
1.0 installations. Surely in the next future release after 1.4 this can
be forced to be changed to utf-8, maybe avoiding any kind of
responsability for still keeping old and unmaintained 1.0.x releases.
This means please keep using your current charset for contributing, and
if you want, and find that you miss some functionality, then test utf-8
and report about it (if it's a bug).
What I consider the most important of all is that if I take this
decision alone this can affect the whole application behaviour and data,
and this is beyond my role, unless the core developers agree with it.
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
I vote for UTF-8. I had troubles with 1.4 version since I convert manually everything to UTF-8.
Characters in ISO-8859-2 was wrong displayed in all emails. This is (I think) because there is used php function html_entity_encode/decode. That function supports very limited amount of character sets.
Everyone, who has unsuported character set will have trouble. ISO-8859-2 is unfortunately unsuported.
There are 2 ways how to solve it. Rewrite that functions or switch to UTF-8.
I don't see any problems in my UTF version, but I must say that I use limited functionality right now.
Only email and calendar.
