Future of developer tools (aka translation tools)

Oscar_Manuel_Gomez_S 2009-12-30 22:11:26 UTC #1

Hi, all.

I’ve recently exchanged emails with Ralf and the Stylite people in order
to propose some changes about the translation tools. But some months
ago, Stylite paid an interim to do a rework and improve translation
tools, but Ralf didn’t have time to review and commit it. So, Ralf has
asked me to take a look and commit it, but before this a decision is
needed in order to go on one direction.

So, the current status is that the rework done is very nice and has some
improvments, like using the etemplate widgets in order to do some
filtering, like missing strings or “paging” of the app to be translated.

There’s one point I think we all agree: the name “developer tools” is
not accurate, and this is a great opportunity to improve the situation,
being one way or another valid choices.

But the intention of Stylite is to fully integrate the new code into
etemplate, so it will be mandatory that the translation people is
granted access to etemplate app in order to translate. Unlike the
tranlation statistics page, I think this situation would affect as many
installations as anybody is a potential translator, not to mention team
work or companies hiring translators. where it should be mandatory to
give access to the etemplate app to the translators.

The other way would be to port the code to a new separate app (i.e.,
“translate”, but suggestions for the name are welcome) and act like the
"new generation of translation tools". The translation people only need
to be given access to this app in order to translate.

Surely current translation tools would be deprecated after some time
with any of the choices, but it’s still future.

Also, regardless the choice, I’ve had to do some changes in this rework
just to adapt it to current trunk, but some more things are needed. The
big problem comes because these changes depend on the way the new code
will be placed into egw tree, and it would be a waste of time doing them
in the “wrong” direction. So, before going on, I’d like people to
express their opinions and experience when translating and the
suggestions about what you think it’s the best solution, i.e, putting
everything into etemplate or as a separate app.

Happy christmas and new year for everyone.

–

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

This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon’s best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev

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

Oscar_van_Eijk-3 2009-12-31 08:19:01 UTC #2

Oscar, All,

IMHO, integrating Translation tools into Development tools is only useful if
they are always used together, but in my experience, that hardly ever
happens.
When I write code, I do create the Dutch translations immediatly, and I
suppose most developers create the English version of new updates with only
a translation in their own language.
All other translations are added later by other people, which makes is to
seperate roles in my opinion.
I’d say, create a different app for. As a name, I’ld suggest "eTranslate"
which makes the link with eTemplate obvious.

My 2cents.

Let me end with wishing everybody all the best for 2010! Enjoy it!
Oscar

egroupware-developers@lists.sourceforge.net, “Ralf Becker” rb@stylite.de,
“Stefan Becker” sb@stylite.de, “Klaus Leithoff” kl@stylite.de

Hi, all.

I’ve recently exchanged emails with Ralf and the Stylite people in order
to propose some changes about the translation tools. But some months
ago, Stylite paid an interim to do a rework and improve translation
tools, but Ralf didn’t have time to review and commit it. So, Ralf has
asked me to take a look and commit it, but before this a decision is
needed in order to go on one direction.

So, the current status is that the rework done is very nice and has some
improvments, like using the etemplate widgets in order to do some
filtering, like missing strings or “paging” of the app to be translated.

There’s one point I think we all agree: the name “developer tools” is
not accurate, and this is a great opportunity to improve the situation,
being one way or another valid choices.

But the intention of Stylite is to fully integrate the new code into
etemplate, so it will be mandatory that the translation people is
granted access to etemplate app in order to translate. Unlike the
tranlation statistics page, I think this situation would affect as many
installations as anybody is a potential translator, not to mention team
work or companies hiring translators. where it should be mandatory to
give access to the etemplate app to the translators.

The other way would be to port the code to a new separate app (i.e.,
“translate”, but suggestions for the name are welcome) and act like the
"new generation of translation tools". The translation people only need
to be given access to this app in order to translate.

Surely current translation tools would be deprecated after some time
with any of the choices, but it’s still future.

Also, regardless the choice, I’ve had to do some changes in this rework
just to adapt it to current trunk, but some more things are needed. The
big problem comes because these changes depend on the way the new code
will be placed into egw tree, and it would be a waste of time doing them
in the “wrong” direction. So, before going on, I’d like people to
express their opinions and experience when translating and the
suggestions about what you think it’s the best solution, i.e, putting
everything into etemplate or as a separate app.

Happy christmas and new year for everyone.

–

—|

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 |

—|

This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon’s best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and
easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev

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

–

Oscar van Eijk

Oveas Functionality Provider
Zwaardenburg 63 – 3437 RJ Nieuwegein
T: +31(0)30 - 889 7812 – F: +31(0)30 - 889 9117
[http://oveas.com – info@oveas.com ->
http://oveas.com]

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

sbegw 2009-12-31 10:40:57 UTC #3

Hi Oscar,

what do think a bout putting a ACL behind the etemplate app, so that the
new translating thing can be placed unter etemplate und you can dedice
if the users have ony access to Tranlation Tool, changing Data Struktur
and so on.

Stefan

Oscar Manuel Gómez Senovilla schrieb:

Hi, all.

I’ve recently exchanged emails with Ralf and the Stylite people in
order to propose some changes about the translation tools. But some
months ago, Stylite paid an interim to do a rework and improve
translation tools, but Ralf didn’t have time to review and commit it.
So, Ralf has asked me to take a look and commit it, but before this a
decision is needed in order to go on one direction.

So, the current status is that the rework done is very nice and has
some improvments, like using the etemplate widgets in order to do some
filtering, like missing strings or “paging” of the app to be translated.

There’s one point I think we all agree: the name “developer tools” is
not accurate, and this is a great opportunity to improve the
situation, being one way or another valid choices.

But the intention of Stylite is to fully integrate the new code into
etemplate, so it will be mandatory that the translation people is
granted access to etemplate app in order to translate. Unlike the
tranlation statistics page, I think this situation would affect as
many installations as anybody is a potential translator, not to
mention team work or companies hiring translators. where it should be
mandatory to give access to the etemplate app to the translators.

The other way would be to port the code to a new separate app (i.e.,
“translate”, but suggestions for the name are welcome) and act like
the “new generation of translation tools”. The translation people only
need to be given access to this app in order to translate.

Surely current translation tools would be deprecated after some time
with any of the choices, but it’s still future.

Also, regardless the choice, I’ve had to do some changes in this
rework just to adapt it to current trunk, but some more things are
needed. The big problem comes because these changes depend on the way
the new code will be placed into egw tree, and it would be a waste of
time doing them in the “wrong” direction. So, before going on, I’d
like people to express their opinions and experience when translating
and the suggestions about what you think it’s the best solution, i.e,
putting everything into etemplate or as a separate app.

Happy christmas and new year for everyone.

–
Stylite GmbH
[ open style of IT ]

Morschheimer Strasse 15
D-67292 Kirchheimbolanden

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

Geschäftsführer: Andre Keller,Gudrun Müller und Ralf Becker
Registergericht Kaiserslautern, HRB 30575
USt-ID: DE214280951

www.stylite.de

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

Oscar_Manuel_Gomez_S 2010-01-05 08:25:29 UTC #4

Stefan Becker escribió:

Hi Oscar,

Hi, Stefan.

what do think a bout putting a ACL behind the etemplate app, so that the
new translating thing can be placed unter etemplate und you can dedice
if the users have ony access to Tranlation Tool, changing Data Struktur
and so on.

Well, there’s one thing I didn’t ask and I’m not sure to understand: why
do you think that the translation should be part of etemplate, or even
why do you think the translation shouldn’t be a separate app?

Apart from that, my namesake Oscar van Eijk also thinks that they
shouldn’t be together.

Now directly answering your question, I already thought about that, but
found that dedicating the time to develop to make it work safely may not
deserve the effort, and setting that up makes more difficult the
administration itself, and even would make the (us) admins wonder “why
have these people changed this? It was nice before. I hope this really
works as they intend”.

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

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

Oscar_Manuel_Gomez_S 2010-01-05 08:30:09 UTC #5

Oscar van Eijk escribió:

Oscar, All,

Hi, Oscar.

IMHO, integrating Translation tools into Development tools is only useful if
they are always used together, but in my experience, that hardly ever
happens.
When I write code, I do create the Dutch translations immediatly, and I
suppose most developers create the English version of new updates with only
a translation in their own language.
All other translations are added later by other people, which makes is to
seperate roles in my opinion.
I’d say, create a different app for. As a name, I’ld suggest "eTranslate"
which makes the link with eTemplate obvious.

I think this idea is very good. I second it.

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

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