Menu/Command capitalization

Fri Jan 8 16:06:16 UTC 2016

In data venerdì 8 gennaio 2016 12:51:35, Jaroslaw Staniek ha scritto:
> 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.

Just like any language among the ones in our repositories: if there's
interest, somebody will step up and do the work.

> 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.

I'm not sure why you're going that far in thinking about forking, only
for this. Forking has a cost, and if all you need is just provide
different texts to user-visible strings, then maintaining a separate
translation is a lot easier to maintain; this works even in the worst
case, that is when such translation is maintained privately and not
shared among the KDE community.

> 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.

Demand from who?

> 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.

-1

> >> - 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.

This is totally different issue, that is lack of periodic style reviews
in our libraries and applications; we do have one style, we just don't
"enforce" it properly everywhere.

> >> - 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

Sure, two classes of OSes. Regardless, what I said above still stands.

> 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).

I don't see how "there are more Windows desktops than KDE" made us do
style choices in the past that do something else than what Windows does.

> > 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.

Exactly, you said that yourself as well: there is simpliy nothing to
change in our strings. Other than that, as I mentioned already, we just
need to apply our HIG more.

> 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.

If you are writing something KF5-based, then the current HIG apply to
them, regardless what Windows, iOS, or Android have as style in their
messages. It is difficult already to make all our libraries and
applications *coherent* between each other, so don't make this even
more messier by choosing your own style.

Thanks,
-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160108/f375bf32/attachment.sig>