Re: [eGroupWare-developers] Proposal for changing the lang files directory

classic Classic list List threaded Threaded
1 message Options
Oscar Manuel Gómez Senovilla Oscar Manuel Gómez Senovilla
Reply | Threaded
Open this post in threaded view

Re: [eGroupWare-developers] Proposal for changing the lang files directory

Hash: SHA1

Hi all.

About the proposal I wrote some time ago (quoted below) I've received
Ralf's permission to go ahead with it. So, in a few moments, I'll commit
a patch (the proposal is for trunk only) whose first effects are:
1) Hopefully, everywhere a lang file is needed to be loaded, the paths
for searching the lang files will be <app>/lang/egw_*.lang (new),
<app>/setup/egw_*.lang (still current) and <app>/setup/phpgw_*.lang (old
for backwards compatibility), in this order, winning only the first one
2) Will NOT automatically create the new (<app>/lang/) dir. After the
patch, during this weekend, I should be able to migrate all the apps in
trunk from setup/egw*.lang to lang/egw_*.lang. So, if if between the
commit of the patch and the migration of an app a translator uses the
developer_tools in order to do a translation, this will (try to) go
directly into <app>/lang/egw_XX.lang, so in this case he should create
the lang dir himself and provide write permissions for the webserver.

I'm not 100% sure, but at least because of translation, you can remove
the write permissions for every <app>/setup directory. I'll try to add
in check_setup something about this.

I hope everyone is happy with this change.


> I'd like to know your opinion about I've been thinking about for a lot
> of time, but never had the time to do it.
> As surely (at least) most of you know, egw has always placed the
> translation files (egw_*.lang) in a directory called <app>/setup/,
> except for the "setup" application itself, being in setup/lang/ directory.
>  From my point of view, this has several problems:
> 1) Mix code files (.php files) in the setup directory together with
> non-code (lang files) in the same directory. I think this is at least
> somehow dirty, and most of the l10n-aware php apps I know dedicate a
> directory for lang files only.
> 2) Extra coding, because depending on the app, the lang files are
> located in one directory or another.
> 3) No need for translators to write in the setup directory, just one
> specific and well-known directory. Also, I can't think at this time (for
> most users) of any reason to write in the egw tree (maybe only if the
> developer tools -aka translation tools- are installed).
> There maybe others, but these are enough to me.
> So, I propose to create and use the 'lang' directory in every app to
> host the lang files. I've been taking a look and I think everything is
> in the translation class. The problems that I think that can be found
> with this change are:
> 1) The amount of work to be done. I think I can (I'll try to) do it
> myself, but before committing code, I'd ask the changes to be granted,
> for if there was something wrong, or bad coding style, etc.
> 2) The change would be only in trunk, so stable releases wouldn't be
> affected. Hopefully next stable release > 1.7 (I haven't seen any
> roadmap about it).
> 3) There has to be some backward compatibility (as it happened when I
> changed the prefix from 'phpgw*.lang' to 'egw*.lang'), because there are
> some apps running on top of egroupware not being part of the egw
> repository itself that would need to change if using the latest trunk,
> so there must be some time for them and their users to not force the change.
> Well, what do you think?
> Regards.

- --
| info: Linux user: 92390 - Linux machine: 39301 |
|        Oscar Manuel Gómez Senovilla -        |
|                 GPG Key at                  |
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.
eGroupWare-translation mailing list
[hidden email]