Could I request a missing item for translations: currently, there's absolutely NO ways of entering non-breaking spaces in translations, despite some translations require them. When we submit a translation string using the online web form, these non breaking spaces become regular spaces, which is wrong when NBSP are needed for example with some punctuation signs (in French for example, or as group separators in decimal numbers). This causes some messages to display with an incorrect line-break when lines are wrapped (for example an undesirable linebreak in the middle of a number, or between a word and a punctuation). Currently the web form displays non-breaking spaces as "[nbsp]" but trying to enter this in the web form does not recreate the expected code, but enters the "[nbsp]" string as a litteral. So please, make sure that the web input form are processed correctly: don't convert non-breaking spaces from the input form into regular spaces. Similar problems occur also with some format controls needed for some languages, notably: - direction controls for embedding multiscript texts: LRE, RLE and LRM (often needed for embedding Latin fragments including punctuation, to avoid incorrect reordering or mirroring notably at the inter-script boundaries). - word-breaking controls: ZWJ, ZWNJ (really needed for supporting South-Asian scripts) - combining grapheme controls (needed because of Unicode normalization): CGJ (really needed for supporting Hebrew, due to the way Hebrew combining points in full-pointed texts are normalized because of the "incorrect" but unchangeable combining weights that are assigned to Hebrew combining points; with CGJ, the reordering of multiple Hebrew points can be blocked during normalization; this CGJ is normally not needed for modern Hebrew as there are normally only one point per Hebrew base letter, but this still occurs with vowel points added on letters with a dagesh or resh point; the Hebrew combining marks were given default combining weight assuming only the modern usage, but problems happen immediately when you have to manage Biblic and other religious texts that use a lot of additional combining marks, including cantillation). Or suggest an input syntax for allowing entering them, for example by using a "\uNNNN" notation (if the texts contain litteral "\u" convert them first to "\\u" before displaying them and allowing them to be entered in the input form). The Javascript in the input form could be used to redisplay these controls correctly (for example displaying "[nbsp]" with smaller letters, within a box with greyed background), and could use this trick to support correct input of litteral backslashes (entered as "\\" internally but viewed as a "\" in a greyed box), or newlines others than single U+000A. But currently, the current code alters/destroys the existing non-breaking spaces in existing translations submitted to Lauchpad. This makes the Launchpad website not very suited for handling international texts, notably for the "Translations" where this is really needed! > -----Message d'origine----- > De : launchpad-users-bounces@xxxxxxxxxxxxxxxxxxx [mailto:launchpad-users- > bounces@xxxxxxxxxxxxxxxxxxx] De la part de Carlos Perelló Marín > Envoyé : mercredi 21 novembre 2007 12:41 > À : Ubuntu translators > Cc : launchpad-users > Objet : Call for testing new Launchpad Translations code performance
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)