In data venerdì 8 gennaio 2016 12:51:35, Jaroslaw Staniek ha scritto: > On 8 January 2016 at 00:28, Pino Toscano <p...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
