Re: [eGroupWare-translation] [eGroupWare-developers] Switch language files to utf-8

[<om...@es...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[CCing translation list]
Ralf Becker escribió:
> Hi Oscar,
> 
> I think on the long run using utf-8 as charset for all lang-files is the
> right way to go.


I just wonder if right now is the run is long enough to start using
utf-8 for all lang files in trunk.


> I would use the same filename (egw_*.lang) and not an other - even more
> complicted - one.


Of course, but I did this just for testing and not break existing files
if something was going wrong.

At this time, I have tested spanish (es-es) and there seems to be no
problem at all. I'm doing the tests at my laptop, and then, I'd commit
the changes and update my public site with it. With a script I've
created, I think all installed lang files in all apps are handled,
that's why I've provided it.


> I dont think we need an api update, but we should preserv the current
> install charset. Eg. if the install is iso, we should leave it iso and
> not automatically update it to utf-8. New installs are a different case.


I agree, but I'd like to try to prevent side effects in application
data. For instance, if an application gets updated, I guess the
installed lang files get affected (i.e. reloaded or updated with new
phrases), so the lang tables would be upgraded to utf-8. Production
environments shouldn't be affected by this until next stable release. Of
course, production environments shouldn't use trunk, but if they do,
they have been warned of what can happen at any time. Without
investigating too much, and mainly depeding on the db engine, I think
that as long as it is possible to specify different charsets per table
(or the db engine can isolate charsets in a per table basis), there
should be no problem.


Anyway, the question, after having done some successful tests locally,
are there any problems to commit during today the new lang files? I've
seen, when installing all languages and enabling debug, that some
phrases have some problems, but I find they are very few and surely
they're somehow outdated.


Regards.

> Ralf
> 
> Oscar Manuel Gómez Senovilla schrieb:
>> Ralf Becker escribió:
>>> Hi Oscar,
>>> no sure anyone is still on this list, it was never public.
>>> You should ask that question on the developer list again.
>>
>> Yes, I know and I'm aware of that.
>>
>>
>> - From previous mails, I don't remember any objection about fully
>> switching (at least lang files) to utf-8, but my intention was to take
>> care about (at least) two involved issues with the change:
>>
>> 1) I'm not personally coding any situation beyond reloading (or first
>> time install) lang files or apps from /setup or translation tools. This
>> means that it might be an api ugrade, or some action should be taken
>> from /setup
>> 2) Coordinate with any other change that could be broken with this in trunk.
>>
>>
>> Of course, there might be another issues. Once these issues are covered
>> at app level in egw code, then face the translation issues in a later
>> stage with direct help from translators.
>>
>>
>> I attach a bash script that copies/links (depending on if the lang file
>> is already using utf-8 or not) the "_utf-8" suffix to every existing
>> langfile, together with setting utf-8 as charset in both phpgwapi and
>> setup. The script needs to be set some path if you want to test it
>> yourself. Once validated, the script could also do "svn remove/add" as
>> appropiate (as I did with the change from phpgw to egw prefix) in the
>> changed lang files.
>>
>>
>> Regards.
>>
>>
>>> Ralf
>>> Oscar Manuel Gómez Senovilla schrieb:
>>>> Hi, all.
>>>>
>>>>
>>>> Here in Spain we're having a long weekend, and I'd like to face one
>>>> somehow long-standing issue: fully switch to utf-8 for lang files. I
>>>> think I'll have enough free time to do it all, but I'd like to have an
>>>> active cooperation from translators (where I'll mail later after the
>>>> approval) of the method to make it work.
>>>>
>>>> The basic method I'll follow is to use iconv to convert from the current
>>>> charset (I'll try the specified charset in phpgwapi as source charset,
>>>> there should be no problem). Then, I'll change the phrase for the
>>>> charset in both phpgwapi and setup, and as long as it works, I'll go
>>>> trying lang by lang. After a successfull switch for all existing
>>>> languages, I'll face the changes to remove the phrases specifying a
>>>> charset and, optionally, ignore whatever can be left in the phrases and
>>>> harcode the use of utf-8 in the translation class.


- --

|----------------------------------------------------------------------|
| 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

iD8DBQFHNFW5Qpr3kykd/aQRAiEIAJ9lYPU8oh1iVHpWIqI9tr7mRugirQCeN/GQ
syuUnBdYi7smvRPga0swSUk=
=Cl14
-----END PGP SIGNATURE-----