Please read: minutes of ESC meeting

l10n
#1

Hi all,

Concerning current workflow, here are the minutes of the ESC meeting and
the result of our discussions whit Christian:

* l10n (Sophie)
    + is bad.
    + many strings are marked fuzzy / not cleaned yet (Cloph)
       + many can be auto-translated but need a script writing.
       + wizards cause problems (from gettext migration)
           + different things there (Caolan)
       + some instances where English source string is changed
           + will still be fuzzy afterwards.
    + translators should be a bit patient (Sophie)
       + focus on writer & calc where chance of un-converted strings is
low (Cloph)
          + plan to have a script for next week

So please be patient, we are looking after it and will try our best to
clean the situation.
Cheers
Sophie

#2

Some thoughts for guys capable of implementing. Of course, I have no idea whether any of these are feasible.

So, change in English string (tEh original) brings some checks with the previous value:
1) capitalisation changed? set flag 1
2) shortcut markup changed (like _ to &)? set flag 2
3) typography changed (like ... to …)? set flag 3
4) something else which nobody in the world *needs* to react to?

Then, the flags for the strings are checked against the matrix of 'action values' for those flags and languages.

Just sketching:
'ru', caps=no_reaction, shortcut=autochange (change just the marker in the translated), typography=autochange (no error if there's no corresponding), words_changed=react (!)

No 'criticality' in the matrix means the new original is set with the 'NONCRITICAL' (not FUZZY!) flag (needs to be implemented, at least in the online l10n system?). The team would wish to see and check those changes, after all.
And even one 'criticality' sets the FUZZY flag, etc.

-Yury

#3

You mean that system automatically replace shortcut position or just character: _New : ~New : N_ew : N~ew.

This could be tricky.

Kruno

#4

This can not be done by a script, you don't mark the access key at the
same place depending on the language because there should be no
duplicates when there is a submenu.

Cheers
Sophie

#5

Just the marker char, providing its activator char wasn't changed. Then you could auto-change the translated string(s) -- provided there'd be no ambiguities in the translation (like extra pairs of chars starting with the old marker).

Should/would work even for activation char translated.

#6

+1 to all of these.

Michael

Sgrìobh Yury Tarasievich na leanas 17/10/2017 aig 08:39:

#7

Yes, yes, yes! Thank you Yury for these suggestions. Maybe Dwayne could comment on feasibility?

Rhos

Ar 17/10/2017 10:11, ysgrifennodd Michael Bauer:

#8

I guess changes in quotation marks ('→" "→ˮ) inside of text strings would fall into category 3)?
Either translators will have localized them («french quoted text») or they're fine with what's already there.

One frequent case for category 4): When there's a typographic symbol like an ' (apostrophe), which may not be used at all or is used very differently in the target language; I don't count anymore all the fuzzies I've had because someone corrected "it's" to "its" or vice versa (and in my language we don't use these). Of course more serious spell-checking in source could possibly alter the conveyed meaning for translators, thus it could be justifiable to make things fuzzy in that case.

Just thoughts,

Sveinn í Felli

Þann þri 17.okt 2017 07:39, skrifaði Yury Tarasievich:

#9

I guess changes in quotation marks ('→" "→ˮ)
inside of text strings would fall into category 3)?

I'd say those, as culture-dependent, would merit a separate category. OTOH, ellipsis vs. three-dots is implementation-specific (so, #3).

One frequent case for category 4): When there's
a typographic symbol like an ' (apostrophe),

Apostrophe-to-doublequote definitely #3. Apostrophe-to-apostrophe (like, U+0027 to U+20xx)... *rather* #3.

In fact, there's no need to create a complete matrix of things typography-related, but rather those actually being implemented and the most likely scenarios.

-Yury