Re: Proposal to change l10n system (WAS: DDTSS is down)
On 28 January 2011 00:32, Eric Spreen <eric-debian@ericspreen.nl> wrote:
> Considering the implementation of the DDTSS, I think that a few things
> could be improved. First of all I don't think that web interfaces are
> the best way to provide access to a system that uses very much different
> encodings, since standard HTML is not very compatible with it. Of course
> new standards such as XHTML and HTML 5 support all kinds of encodings,
> but not every browser supports them (especially legacy CLI browsers)
> and many browser implications that do suck at it.
One of the hardest things about getting the interface to work was
getting the encoding stuff right. It took a bit of work but the result
works well. In particular, just about every browser (with the
exception of Konq IIRC) can be convinced to transmit the encoding of
the POST data as a variable. Yes, even old versions of IE. This makes
misinterpretation of the user data essentially impossible.
On any modern browser everything is sent and received in UTF-8, but it
also works if the browser is stubborn (happens for some east-asian
languages and old browsers). The last bug I heard w.r.t. encodings is
a very long time ago now.
Your suggestions for a commandline interface are interesting, but I
don't think realistic. You'd need some kind of communication between
the editor and whatever provides the descriptions. You could actually
do this with the email interface, but encoding problems were rife
there (SMTP is even less clear than HTML).
> For example, as
> Martijn noted in the DDTSS self, many browsers display a non-breaking
> space as a period.
Actually, this is deliberate. Some languages use them a lot and
without this "modification" you can't tell the difference between a
breaking and non-breaking space.
> Secondly, the system should obviously be implemented more stable. The
> debugging should be done very carefully and there should be enough
> people who know about it's internals in order to perform regular
> maintenance. (I suggest C, but then again, I am a script analphabetic)
*All* of the stability problems come from the crappy database used. If
we decide the interface isn't the worst, then redoing the database
layer to use the existing PostgreSQL database on the machine with an
appropriate schema would make the whole system much more reliable (and
probably faster too).
> That being said, I would like to add that the DDTSS is by far the most
> user friendly and intuitive project interface I have seen for all
> running l10n projects.
Thanks. I actually thinks there's a lot of potential still. For
example, finding paragraphs that differ by a single word and finding
that word in the translation and fixing it (catches many stupid
situations where only a version number changes). Or providing google
translate suggestions inline.
> This is were my original idea for combining all translation projects
> into one interface comes in. Since the DDTSS needs reimplementation, or
> at least very much code hacking, it would not be a very great effort to
> integrate existing interfaces - such as the status scripts, the po index
> pages, etc - into a new/updated system.
Do note that the DDTSS is currently very oriented toward descriptions,
the summary, the 80 bytes width, paragraphs, etc. Though I agree the
DDTP webinterface and DDTSS could be more tightly integrated and
receive a face lift. The DDTP part is easy, all the info is in a Pg
database, if someone coded something up in Django (for example) it
could be deployed fairly easily (DDTP interface is very little code).
Thanks for the thoughts.
--
Martijn van Oosterhout <kleptog@gmail.com> http://svana.org/kleptog/
Reply to: