Proposal for changing the lang files directory

[Oscar_Manuel_Gomez_S]

Hi.

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 /setup/,
except for the “setup” application itself, being in setup/lang/ directory.

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.

–

----------------------------------------------------------------------|
http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 |
Oscar Manuel Gómez Senovilla - omgsATescomposlinux.org |
GPG Key at http://keyserver.pgp.com |
----------------------------------------------------------------------|

---

Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Ralf_Becker_6]

Hi Oscar,

Oscar Manuel Gómez Senovilla schrieb:

Hi.

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

One could argue lang files are in setup directory, as they are used
(like the other stuff in that directory) only during setup time.

2. Extra coding, because depending on the app, the lang files are
   located in one directory or another.

So far every change in the lang files, created more extra code, as we
either have to change all old apps too, or add support for the old and
new location/name, as we did with the last change.

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

Sorry to say: in my opinion that creates far more trouble then it’s worth!

Specially for us (Stylite), as we create our EPL releases from Trunk
every half a year (as we do it ever 1-2 years with community releases).

Merging of translations from Trunk back into a branch becomes a lot
harder, if it’s not the same file.

A compromise might be to just rename setup’s lang directory to setup
too. That would in fact same some extra code.

Ralf

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.

–
Ralf Becker
Director Software Development

Stylite GmbH
[open style of IT]

Morschheimer Strasse 15
67292 Kirchheimbolanden

fon +49 (0) 6352 70629-0
fax +49 (0) 6352 70629-30
mailto: rb@stylite.de

www.stylite.de
www.egroupware.org

---

Geschäftsführer Andre Keller,
Gudrun Müller, Ralf Becker
Registergericht Kaiserslautern HRB 30575
Umsatzsteuer-Id / VAT-Id: DE214280951

---

Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Oscar_Manuel_Gomez_S]

Ralf Becker escribió:

Hi Oscar,

Hi, Ralf.

Oscar Manuel Gómez Senovilla schrieb:

Hi.

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

One could argue lang files are in setup directory, as they are used
(like the other stuff in that directory) only during setup time.

Well, let me disagree. If I’m not wrong they’re used:

• During setup time
• During login time
• Intensively during “translation” time (i.e. translators), in write mode.
• During the translation module in sitemgr (yes, rarely used in production)?

I didn’t mention, because I found it obvious, that the perspective that
led to do this proposal is to take a look from a translator point of
view more than from a developer’s one, but of course I take it into
account, and I want to minimize the dedicated time by a developer to
this task, that can be “annoying” for him.

2. Extra coding, because depending on the app, the lang files are
   located in one directory or another.

So far every change in the lang files, created more extra code, as we
either have to change all old apps too, or add support for the old and
new location/name, as we did with the last change.

Yes, I already mentioned that, and I’ll take care about both locations.

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

Sorry to say: in my opinion that creates far more trouble then it’s worth!

I agree that for a developer the rate of dedicated time will not revert
in something useful to him, but I think this change would become egw a
more “translation-friendly” suite.

Specially for us (Stylite), as we create our EPL releases from Trunk
every half a year (as we do it ever 1-2 years with community releases).

Merging of translations from Trunk back into a branch becomes a lot
harder, if it’s not the same file.

Well, if you’re very about to release one of these EPL releases, then
this change could wait until then, and “go mature” during about the next
six months after the release. Anyway, the change would be atomic, so the
apps that would have the change would be all or none, and there should
be no problem. Also, if some app (for any reason) would be using the old
(current) directory, there will be backwards compatibility.

A compromise might be to just rename setup’s lang directory to setup
too. That would in fact same some extra code.

Well, I think you mean “save” instead of “same”.

Regards.

Ralf

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.

–

----------------------------------------------------------------------|
http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 |
Oscar Manuel Gómez Senovilla - omgsATescomposlinux.org |
GPG Key at http://keyserver.pgp.com |
----------------------------------------------------------------------|

---

Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Oscar_Manuel_Gomez_S]

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 /lang/egw_.lang (new),
   /setup/egw_.lang (still current) and /setup/phpgw_*.lang (old
   for backwards compatibility), in this order, winning only the first one
   found.
2. Will NOT automatically create the new (/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 /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 /setup directory. I’ll try to add
in check_setup something about this.

I hope everyone is happy with this change.

Regards.

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

---

----------------------------------------------------------------------|
http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 |
Oscar Manuel Gómez Senovilla - omgsATescomposlinux.org |
GPG Key at http://keyserver.pgp.com |
----------------------------------------------------------------------|

---

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. http://p.sf.net/sfu/bobj-july

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Oscar_Manuel_Gomez_S]

Oscar Manuel Gómez Senovilla escribió:

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:

Hi.

I’ve just committed the patch (it took some extra time due to on-the-fly
conflict unexpected by me within few minutes, sorry Ralf) and it works.
However, there’s one test I didn’t (it’s not to blame on this, since it
happened before) that when trying to remove one language for reinstall,
there’s an error, saying

Warning: Invalid argument supplied for foreach() in
…/phpgwapi/inc/class.config.inc.php on line 96

Should I open a bug report?

Meanwhile, I’ll start moving phpgwapi lang files first, and then, the
rest. I’m going to leave out for the moment (unless explicit
confirmation) like gallery,mydms,phpfreechat or workflow where I’m not
100% sure if people use the updated trunk checkout with non-trunk or
older versions of egw not available (or bug-fixed) in stable branches.
When I’m finished, I’ll report and wait for confirmation for any missing
app.

Regards.

---

----------------------------------------------------------------------|
http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 |
Oscar Manuel Gómez Senovilla - omgsATescomposlinux.org |
GPG Key at http://keyserver.pgp.com |
----------------------------------------------------------------------|

---

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. http://p.sf.net/sfu/bobj-july

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Hans-Jurgen_Tappe]

Hi Oscar!

Oscar Manuel Gómez Senovilla schrieb:

Meanwhile, I’ll start moving phpgwapi lang files first, and then, the
rest. I’m going to leave out for the moment (unless explicit
confirmation) like gallery,mydms,phpfreechat or workflow where I’m not
100% sure if people use the updated trunk checkout with non-trunk or
older versions of egw not available (or bug-fixed) in stable branches.

As far as I can see, you can do the updates also for gallery nd phpfreechat.

• For gallery, there is currently no need to use trunk over 1.6.003
  because there is no additional feature or bug fix which is not
  available in both versions as far as I know.
• phpfreechat was designed for trunk and if people need that in the 1.6
  branch, there was a static version which did not touch the database (I
  am not even sure if the current trunk version would install cleanly in
  1.6) - or people would have to move back their lang files… There is
  only three lang files (_en, _de, _hu) in there anyway.
• For mydms, I do not have any experience.

We should ensure that these two applications can be used for other
integration projects which should then use the new directory structure.
So in my opinion, we should not skip theses modules.

Best regards,
Hans-Jürgen

---

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. http://p.sf.net/sfu/bobj-july

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Oscar_Manuel_Gomez_S]

Hans-Juergen Tappe escribió:

Hi Oscar!

Hi, Hans-Juergen

Oscar Manuel Gómez Senovilla schrieb:

Meanwhile, I’ll start moving phpgwapi lang files first, and then, the
rest. I’m going to leave out for the moment (unless explicit
confirmation) like gallery,mydms,phpfreechat or workflow where I’m not
100% sure if people use the updated trunk checkout with non-trunk or
older versions of egw not available (or bug-fixed) in stable branches.

As far as I can see, you can do the updates also for gallery nd phpfreechat.

• For gallery, there is currently no need to use trunk over 1.6.003
  because there is no additional feature or bug fix which is not
  available in both versions as far as I know.
• phpfreechat was designed for trunk and if people need that in the 1.6
  branch, there was a static version which did not touch the database (I
  am not even sure if the current trunk version would install cleanly in
  1.6) - or people would have to move back their lang files… There is
  only three lang files (_en, _de, _hu) in there anyway.
• For mydms, I do not have any experience.

We should ensure that these two applications can be used for other
integration projects which should then use the new directory structure.
So in my opinion, we should not skip theses modules.

I’m not sure what you mean with “skip”, unless it means “leave
untouched” (i.e. you can migrate their lang files to “lang” directory).

About mydms, I see there are specific directories in both trunk, but
trunk seems to have specific adaptations for trunk, and 1.6 has as
highest revision 28327, that is much higher than what is in trunk, so I
think noone should use mydms trunk version in 1.6 instead of the one in 1.6.

Anyway, if you confirm about phpfreechat, I’ll also fix a problem with
an ending character that, though I already solved for “en”, it’s still
in “de”, and maybe “hu”.

Regards.

---

----------------------------------------------------------------------|
http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 |
Oscar Manuel Gómez Senovilla - omgsATescomposlinux.org |
GPG Key at http://keyserver.pgp.com |
----------------------------------------------------------------------|

---

Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Oscar_Manuel_Gomez_S]

Oscar Manuel Gómez Senovilla escribió:

Hans-Juergen Tappe escribió:

Hi Oscar!

Hi, Hans-Juergen

Oscar Manuel Gómez Senovilla schrieb:

Meanwhile, I’ll start moving phpgwapi lang files first, and then, the
rest. I’m going to leave out for the moment (unless explicit
confirmation) like gallery,mydms,phpfreechat or workflow where I’m not
100% sure if people use the updated trunk checkout with non-trunk or
older versions of egw not available (or bug-fixed) in stable branches.

As far as I can see, you can do the updates also for gallery nd phpfreechat.

• For gallery, there is currently no need to use trunk over 1.6.003
  because there is no additional feature or bug fix which is not
  available in both versions as far as I know.
• phpfreechat was designed for trunk and if people need that in the 1.6
  branch, there was a static version which did not touch the database (I
  am not even sure if the current trunk version would install cleanly in
  1.6) - or people would have to move back their lang files… There is
  only three lang files (_en, _de, _hu) in there anyway.
• For mydms, I do not have any experience.

We should ensure that these two applications can be used for other
integration projects which should then use the new directory structure.
So in my opinion, we should not skip theses modules.

I’m not sure what you mean with “skip”, unless it means “leave
untouched” (i.e. you can migrate their lang files to “lang” directory).

About mydms, I see there are specific directories in both trunk, but
trunk seems to have specific adaptations for trunk, and 1.6 has as
highest revision 28327, that is much higher than what is in trunk, so I
think noone should use mydms trunk version in 1.6 instead of the one in 1.6.

Anyway, if you confirm about phpfreechat, I’ll also fix a problem with
an ending character that, though I already solved for “en”, it’s still
in “de”, and maybe “hu”.

I believe you really mean “yes, go with these”, so I’ve proceeded with
them, leaving only workflow and jinn, that don’t seem to work properly
with current trunk. I also did the same with mydms for the exposed
reason above. And I also restored a problem that caused the history to
get lost, so with the exceptions above, I think I’m finished with the
directory change. I have to take that if there are no complains, then
everyone is happy with this.

Regards.

---

Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

---

----------------------------------------------------------------------|
http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 |
Oscar Manuel Gómez Senovilla - omgsATescomposlinux.org |
GPG Key at http://keyserver.pgp.com |
----------------------------------------------------------------------|

---

Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers