Future of developer tools (aka translation tools)

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

Future of developer tools (aka translation tools)

[I missed this translation list in the original message]
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
eGroupWare-translation mailing list
[hidden email]