[sane-devel] Spelling mistakes

[Olaf Meeuwissen]

Hi Ralph,

Ralph Little writes:

> Hi,
>
> On Thursday, August 1, 2019, 10:37:21 a.m. PDT, Yuri Chornoivan <yurchor at ukr.net> wrote:
>
>> ...This rule is violated by some
>> developers from time to time to fix insignificant typos but this usually leads
>> to the claims by unsatisfied translators (you can easily find discussions on
>> such incidents in FOSS translator mailing lists, e.g. [1]).
>
> In this case, my intention is not to change the intention of the original strings.

If you change the original string ever so slightly in just about any
way, the corresponding translation will be marked fuzzy.  This is so
that translators can see the changed string and check whether the old
translation is still correct.

As I've mentioned before, translations marked fuzzy will not be used at
run-time.  Translators will have to "unfuzzy" the translation first.

> The proposed changes are largely:
>
> (1) Replace British spellings with standard US (e.g. behaviour->behavior)
> (2) Correct "dodgy" grammar.
> (3) Correct obvious spelling errors: "Liniar"->"Linear"
>
> From the last release, we only got about 4 translation updates and I
> wouldn't like to unnecessarily break the translations that we do have
> further than they currently are. :(

Perhaps the last release did not give translators enough time to update.
Perhaps no-one is paying attention or cares enough (have a look at the
Last-Updated fields :-/).  Perhaps we are not communicating with
translators well enough.  Perhaps our infra-structure is not translator
friendly.

But it still remains the translators job to unfuzzy translations
whenever we fix up bad message strings in our code.  Sub-par strings in
our code are extremely unlikely to result in intelligible translations.

I suggest you go through our message strings and fix up anything out of
the ordinary that you encounter.  Our code should have message strings
that are intelligible to POSIX/C "speakers".  POSIX/C is nominally the
same as en_US, give or take a few computing lingo-isms.

If there's anything you're not sure of, ping the list.  Actually, some
of the strings are hard to translate correctly without extra context.

# BTW, translations don't "break", they will just be ignored until they
# are unfuzzied.

> (2) above might result in translations that are not as accurate, so
> perhaps I could correct the .po files only for (1) and (3), those
> being very trivial, and leave (2) for the translators to properly fix
> up at next release?

I would warn strongly against touching po/*.po files for any language
that you are not intimately familiar with.  I know it's tempting to
unfuzzy because you made some minor change, e.g. s/behaviour/behavior/
or some punctuation change, but it is really best to leave it to each
language's "pro" to do this.

# I know that French has pretty strict punctuation rules that differ
# from English (and my native Dutch), Polish rather uncommon plural
# rules (Arabic too, BTW) and I would hate to get caught in the cross
# fire between politically sensitive language differences (even though
# we don't have any obvious candidate in our list of po/LINGUAS, that
# I'm aware of unless Spanish, Catalan and Valencian fit that bill).

Perhaps that an increase in displayed POSIX/C strings will get people
worked up enough to contribute updated translation :-)

# Here's wishful thinking ...

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join