Menu/Command capitalization

[Jaroslaw Staniek]

On 8 January 2016 at 00:28, Pino Toscano <pino at kde.org> wrote:
> Hi,
>
> In data giovedì 7 gennaio 2016 22:42:18, Jaroslaw Staniek ha scritto:
>> Not too long ago MS Windows has moved from "Title Capitalization" to
>> "Sentence capitalization" for menus and commands:
>> https://msdn.microsoft.com/en-us/library/dn742392.aspx
>>
>> What can we do and should we do something about this?
>
> Nothing IMHO -- see below.
>
>> - For everyone else perhaps it's better to offer something officially
>> or else some people would fork translations or avoid using KDE's code.
>
> You don't need to fork anything, just provide a "translation" on top of
> the untranslated strings.

Thanks for the notes, Pino.
That was not the exact question. What I mean is who provides the translation.
If not KDE, then the whole thing can only be forked unspecified number
of times. In extreme case, if "Foo Bar" is replaced with "Foo bar" _in
the code_, then also the code is also forked. Not good.

Regarding the number of locales, I see things do not look that bad: we
have en_US == C and en_GB only.
Please correct me here.

My idea is to provide extra English translations that are variants of
the originals but with sentence capitalization.
Ideally that would be the two extra:
- en_GBS (based on en_GB)
- en_USS (based on en_US)

(S suffix == Sentence)

I believe both can be largely generated on demand.

Title capitalization is possible to automate (e.g. see
http://titlecapitalization.com) but the opposite direction is even
easier, we "just" need a list of exceptions and ability to control the
process e.g. in a context string. Among others, proper nouns may need
to be kept Uppercase. This is my initial overview.

Technically at Qt level: Having the en_*S locales, our apps/libs would
need to use them under certain conditions (e.g. on Android, Windows)
instead of the original locales. Do nothing e.g. on Mac OS X.

>> - Is automated conversion for capitalization a reasonable approach?
>> Runtime or script-based generation.
>
> Definitely not: please never ever mess up with user-visible strings.

Please see the above, maybe what I propose is nice enough, better than
half of the strings in app in one style (KF5 strings), another in
other style (app strings). Even the same title could have two forms in
the same app.
The same button's text.

>> - Do we have checks for semantic strings and capitalization? If so
>> would they need updates, or?
>
> By hand, when somebody spots a mistake and fixes it.
>
>> - Some (future?) KF5 users would target Windows expecting that the
>> resulting apps look and feel largely native.
>
>> [...]
>
>> - Mac OS X and iOS is consistent with KDE capitalization:
>>   https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/20000957-CH15-SW4
>
> To simplify the situation:
> - right now we are like OS-A but different than OS-B
> - with your proposal, we would be like OS-B but different than OS-A
> So, there would be always a class of users feeling "native" (regarding
> the string capitalization),  and another one feeling "alien".

I've done a small research for you in the original post. There are not
just *two* OSes.
OS-A == Android, Jolla, Windows Phone, Windows Desktop
OS-B == Mac OS X, iOS

And KDE, GNOME (etc): undecided but actually both are OS-B because
their legacy is follows: KDE - Windows (before the world moved to
Sentence cap.), GNOME: Mac OS X.

So neither OS-A nor OS-B is a small group. If anything, OS-A is bigger
in number of potential users (I don't count things like KDE Plasma but
apps).

So there's also question how our apps/KF components look under GNOME.

> Sorry, but I don't see how mass-changing English strings, to end up in
> the very same situation (1 like, 1 different) wrt other OSes. At least
> for me, it has been hard enough to keep KDE applications following our
> style in the last 10+ years, I don't want to start over again.

I understand, the cost of manual work makes no sense. So there's a way
to automate the conversion I hope.
Anyone interested to write a script that adds en_GBS and en_USS locales?

A more important question is also: what to do with new messages, new
apps, libs. I am also asking myself. If 90% of app's installations was
in mobile or Windows, using the sentence style in the code would make
sense.
But this breaks the OS-B support.
So ideal support would be IMHO to stay with current Title
Capitalization in the code and have en_GBS and en_USS locales either
generated or maintained partially by hand.

What I write here is for the record, I am not planning to maintain the
locales except for cases when I need something like this for new
apps/libs/code.

The questions apply to so-called Qt-only development too.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek