RE: Call for testing new Launchpad Translations code performance

["Philippe Verdy" <verdy_p@xxxxxxxxxx>]

Bruno Patri [mailto:bruno.patri@xxxxxxxxx]
> Envoyé : mercredi 21 novembre 2007 19:37
> À : verdy_p@xxxxxxxxxx
> Objet : Re: Call for testing new Launchpad Translations code performance
> 
> > No this occurs as well in IE7, not just Mozilla-based browsers. There's
> > apparently something wrong in the way the content is encoded/interpreted
> in
> > browsers, possibly because it is not correctly encoded to support
> > "alternate" spaces, or because of the encoding used to return the
> submitted
> > form.
> 
> How many translators are using IE ? IE even version 7 is very buggy...

This is a completely out-of-topic (and in fact false) assertion. Any way, I
use both (and I have tried both) IE and Firefox (I don't use Opera).

All browsers have bugs (IE7 is not exempt, but Mozilla Gecko is not exempt
of them as well, as shown in the case of NBSP within Web input forms, that
Mozilla/Firefox is sending as regular space without notice! We really need
to enter "[nbsp]" and not regular NBSP characters, and when correcting a
resource, care must be taken to change back MANUALLY the existing NBSP into
"[nbsp]" before submitting, otherwise they are changed immediately into
normal SPACE's within the input form coming from the web server).

Really, the web-server should simply avoid sending any NBSP in non encoded
form, and in fact the server should escape all characters that are known to
cause problems (they can be decoded by the client using local Javascript,
and Javascript can be used as well during the data validation made by the
submit button so that these characters are reencoded into their escaped
form);

> > Note this:
> >
> > Browsers don't let users enter for example a NBSP character, EVEN IF
> this
> > character is mapped on the keyboard, because this is generally mapped on
> > Ctrl+Space or Strl+Shift+Space and browsers are modifying the keymap and
> > disabling the Control key, or transforming the input as soon as it is
> > entered, even if this input comes from a copy/paste operation...).
> 
> The non-braking space is mapped on Alt+Shift+Space on my keyboard (oss
> fr keymap, it was Alt+Space on former keyboard layouts), and it works
> like a charm with Konqueror. I only need to type [nbsp] when I'm using
> a Gecko based browser.

Note: I don't want a non-BRAKING space, as such spaces are not supposed to
slow down my browser. I hope you spoke about non-BREAKING space (i.e. a
space that prohibits line wraps).

My keyboard layout also has a mapping for NBSP (in fact it has several ones,
including Ctrl+SPACE, or Ctrl+Shift+SPACE, or Ctrl+Alt+SPACE = AltGr+SPACE,
or Shift+Ctrl+Alt+SPACE = Shift+AltGr+SPACE), but none of the two browsers
allow entering it, because of the way it uses some internal key bindings
that are overriding the default keyboard layout: either IE rejects the
keystrokes and generates NO character, Firefox converts the keystroke
silently into a regular space within the HTML input form, and both use one
of these mappings to activate the system menu of the current window.

I may even try to enter Alt+0160, but Mozilla takes the digit 6 to perform
another action when it is pressed along with Alt, despite I am composing a
character, that it interrupts in the middle of the composition (and I have
not release the Alt key!)

Such bugs occur in both IE and Mozilla, that make false assumptions about
"unused" key bindings that they think are safe to use for their own purpose
(but both browsers are violating the ISO standard by not reusing keys that
are normally reserved for locale-specific keyboard layouts).

> > My message is on topic, because this topic is speaking about a new
> Launchpad
> > Translations site, and it is testing some new features (primarily to
> speak
> > about the current performance problem, but this should also include the
> > problems of usability).
> 
> It's actually offtopic. Carlos was asking about future Launchpad
> improvements to solve the timeouts issues in translations.

Well, not so much. His message was mostly about the recent launch of a
staging server (still bogous, because its security certificate is completely
invalid, and does not pass the HTTPS validation performed in browsers, as it
attempts to reuse a certificate made only for the main server, and not
suitable for the new specific "staging.*" subdomain.)

He wanted to announce it so that we use his message to report problems. But
this should include all problems with the staging server, otherwise, the
test would not be so much useful.

As the new server was recently installed, these things must be corrected for
allowing further tests, otherwise the tests will not be enough complete, and
things will be released without being really tested.

For now, I have found a way to solve the timeout issues:
* I have stopped using the interface that allows translating entries by
groups of 10: it does not work, most of the time, due to timeouts (or too
much memory used) when performing its internal (certainly badly optimized)
SQL queries.
* I have stopped using any filters (such as trying to filter only the
resources with the "untranslated" or "need review" status). The filters are
actually taking too much resources on the server, certainly because of a bad
design of the database (incorrect indexes, or malformed SQL queries that
can't benefit of those indexes, or invalid selectivity statistics in some
index, so that the internal SQL optimizer is computing the wrong query
execution plan, and requires performing multiple full table scans requiring
too much server resources...)

In addition, the current design of the web pages and input forms has lots of
problems, as well as the data submission protocol which does not convert the
text with correct escaping to pass the HTTP and/or HTML limitations in
browsers.

My feeling is that escaping NBSP in the "[NBSP]" form is the wrong approach,
a more general escaping mechanism should have been designed (and it becomes
impossible to use the 6 literal "[NBSP]" characters in the translation, as
there's no way to escape the "[" character itself to avoid this
reinterpretation).