Context information needed for isolated words
Hi, There is a widespread problem across many text strings to be translated: some isolated words are gender invariable in English, but not in many languages. For example, let's consider this case of a cascade menu: New Folder File In Spanish (as well as in many languages), "new" is gender sensitive. It can be translated as "nuevo" (when referring to masculine words, like "file") or as "nueva" (when referring to feminine words, like "folder"). If I translate "new" as "nuevo" in Spanish, I would get "Nuevo->Carpeta", which is totally wrong. It would be highly desirable that all the words that appear isolated had a context to ease the task of the translators. For all these words, I would advise against using i18n() and would prefer using i18nc() in source code (or using disambiguation comments in UI files). It's a very common problem for almost all isolated words: automatic, small, etc., especially if they are adjectives. Let's see a specific case in kde-workspace/plasmanetworkmanagement-libs.po: Message #113 is: "Automatic" And is used in these files: editor/settings/ui/802-1x.ui:635[1] editor/settings/ui/connectionwidget.ui:160[2] editor/settings/ui/infiniband.ui:80[3] editor/settings/ui/ipv4.ui:49[4] editor/settings/ui/ipv6.ui:227[5] editor/settings/ui/wificonnectionwidget.ui:141[6] editor/settings/ui/wificonnectionwidget.ui:271[7] editor/settings/ui/wiredconnectionwidget.ui:112[8] editor/settings/ui/wiredconnectionwidget.ui:197[9] And it refers to these topics: i18n: automatic bandi18n: ectx: property (specialValueText), widget (QSpinBox, mtu) i18n: ectx: property (text), item, widget (KComboBox, method)i18n: ectx: property (text), item, widget (KComboBox, band)i18n: ectx: property (text), item, widget (KComboBox, metered)i18n: ectx: property (text), item, widget (KComboBox, peapVersion) i18n: ectx: property (text), item, widget (QComboBox, linkNegotiation) Some of these topics are masculine gender and others are feminine gender, as "automatic" should be. The result is that I can't translate "automatic" correctly in Spanish (and other languages). Going back to the case of the aforementioned cascade menu, the solution would be to use other words: Create New folder New file I think it would be necessary to thoroughly review the translatable words that appear isolated in source code and UI files to provide a context for them. Just my two cents. -- Eloy Cuadra [1] src:/editor/settings/ui/802-1x.ui:635 [2] src:/editor/settings/ui/connectionwidget.ui:160 [3] src:/editor/settings/ui/infiniband.ui:80 [4] src:/editor/settings/ui/ipv4.ui:49 [5] src:/editor/settings/ui/ipv6.ui:227 [6] src:/editor/settings/ui/wificonnectionwidget.ui:141 [7] src:/editor/settings/ui/wificonnectionwidget.ui:271 [8] src:/editor/settings/ui/wiredconnectionwidget.ui:112 [9] src:/editor/settings/ui/wiredconnectionwidget.ui:197
Adding the Abstract Games Suite to the KDE Applications
Hello! In https://gitlab.com/abstractsoftware/abstract-games/-/issues/1, we were invited to add the Abstract Games suite into the KDE Applications, and of course we couldn't refuse! We are a small team of two, who would prefer to remain anonymous if that's OK, and we are hosted on free software (Gitlab) at https://gitlab.com/abstractsoftware/abstractgames. I believe that all aspects of the KDE Manifesto are satisfied. Thank you, the Abstract Developers
Re: Context information needed for isolated words
On Sat, May 2, 2020 at 12:36 PM Eloy Cuadra wrote: > > Hi, > > There is a widespread problem across many text strings to be translated: some > isolated words are gender invariable in English, but not in many languages. > > For example, let's consider this case of a cascade menu: > > New > > Folder > > File > What prevents you from arbitrarily re-naming a particular top level entry? E.g. if you see "New", why not translate it as though it were "Create" if that makes your translation work more naturally? I understand you'd want to stick as close as possible to the upstream default, but languages being languages no doubt someone will point out that verbs, too, could be conjugated differently depending on the object. Or aspect, time, mood, actor, tense, whether or not it is reflexive, medium, or otherwise. It could be that the verb might change completely: i.e that creating a new folder somehow requires a different translation of "create" than creating a new file would. Which might mean that "New > File" is much more appropriate as a starting point for *those* languages, because it avoids all the verb-related pitfalls. English cares very little for any of that, so trying to account for it in English might only serve to render it clumsy and awkward. Conversely there are features which English is very particular about like articles which many other languages don't bother with at all. All in all I think it is just easier if translation teams took some liberties to get the point across rather than hoping for English to become more like their native language. In particular this avoids most of the need for complicated rules about "what words to use when". Regards, - Johan
Re: Context information needed for isolated words
> Hi, Hi! > It would be highly desirable that all the words that appear isolated had a > context to ease the > task of the translators. For all these words, I would advise against using > i18n() and would > prefer using i18nc() in source code (or using disambiguation comments in UI > files). I think you are totally right here. Any developer who wants its application to be translated should care about this, and should use i18nc() instead of i18n() everywhere. I mean everywhere. Even if the context appears clear from the message, a single UI marker as context is little work compared to writing the message itself. This is my opinion as someone who sometimes writes application code, and never translated anything. Honestly, I don’t understand why we have i18n() without c. Do you agree as translator? > Going back to the case of the aforementioned cascade menu, the solution would > be to use > other words: > > Create > New folder > New file If I understand you right, the original translation could stay New->Folder, New->File, but with i18nc it would be possible to use this alternative in other languages. Is that what you mean? And for this example, I think it should be the same in English. First, “create” appears more specific than “new”, and an action called “Folder” makes very little sense itself. Many menu actions can appear alone somewhere, and if Dolphin had a toolbar button called just “Folder”, that would be nonsense. Same for “New”. Cheers, David
Re: Context information needed for isolated words
Am Samstag, 2. Mai 2020, 13:11:55 CEST schrieb Johan Ouwerkerk: > On Sat, May 2, 2020 at 12:36 PM Eloy Cuadra wrote: > > Hi, > > > > There is a widespread problem across many text strings to be translated: > > some isolated words are gender invariable in English, but not in many > > languages.> > > For example, let's consider this case of a cascade menu: > > New > > > > Folder > > > > File > What prevents you from arbitrarily re-naming a particular top level > entry? E.g. if you see "New", why not translate it as though it were > "Create" if that makes your translation work more naturally? One thing which might prevent translators being creative here is that the original strings appearing in the list of catalogs are not having separate context information to them, to make it more obvious how the words are used and in which cases. Even more, as without any context information the same string if appearing multiple times is mapped to a single string in the translation catalogs, and then used in all cases, even when in some languages the proper locale version would be different in the different cases. Also when it comes to style (capitalization etc.). That is why there are all the *i18n*c*() call variants in KI18n. Please take a read of https://api.kde.org/frameworks/ki18n/html/prg_guide.html and all the places talking about context. Also see how context is defined in non-code data, like ui files. And yes, most of the code written in recent years seems to have missed to add context in the i18n calls. The older among us have failed here to properly teach the new generations of contributors about good i18n code. :) Time to improve. So: please use more often *i18n*c*(), especially with single words. And default to use UI markers @[:] in the context. When it comes to the Qt translation system, the context info is given in the optional second parameter to the tr() call (so different order compared to KI18n calls), here called "disambiguation" argument. See https://doc.qt.io/qt-5/qobject.html#tr Cheers Friedrich
Re: Context information needed for isolated words
> On 2 May 2020 12:02 Friedrich W. H. Kossebau wrote: > And yes, most of the code written in recent years seems to have missed to add > context in the i18n calls. The older among us have failed here to properly > teach the new generations of contributors about good i18n code. :) Time to > improve. I expected that somehow. With the new pre-commit CI in GitLab, could we teach one of the code checkers to complain about new i18n() without c? Maybe by deprecating i18n()? And if the string to be translated has only one word (like in the example of “New” or “New...”), it may make sense to require more context than just a UI marker. Yes, I am suggesting to forbid i18n() without c.
Re: Context information needed for isolated words
On zaterdag 2 mei 2020 14:46:12 CEST David Hurka wrote: > > On 2 May 2020 12:02 Friedrich W. H. Kossebau wrote: > > And yes, most of the code written in recent years seems to have missed to > > add > > context in the i18n calls. The older among us have failed here to properly > > teach the new generations of contributors about good i18n code. :) Time to > > improve. > > I expected that somehow. With the new pre-commit CI in GitLab, could we teach > one of the code checkers to complain about new i18n() without c? Maybe by > deprecating i18n()? And if the string to be translated has only one word > (like in the example of “New” or “New...”), it may make sense to require more > context than just a UI marker. > > Yes, I am suggesting to forbid i18n() without c. > That's simply not possible. A quick check in krita shows boud@boud-ThinkPad-T470p:~/dev/4.3$ git grep i18n | grep -v i18nc | wc 4222 25936 531642 boud@boud-ThinkPad-T470p:~/dev/4.3$ git grep i18nc | wc 7706956 114510 There is no way we are going to halt development in order to add context to 4222 translatable strings -- even if we could come up with the context, because, not being translators, we developers don't know what the translators need to have for context in all those 4222 cases. -- https://www.krita.org
Re: Information regarding upcoming Gitlab Migration
On Fri, May 1, 2020 at 10:14 PM Ben Cooksley wrote: > On Sat, May 2, 2020 at 6:17 AM Alexander Potashev > wrote: > > I have a similar use case. Sometimes I need to share a URL to a > > project. For this purpose I used to share e.g. > > https://cgit.kde.org/releaseme.git/about > > > > Does this migration make such permalinks impossible? > > > > > > From what I see, we lose permalinks because > > 1. cgit.kde.org will be discontinued > > We provide the commits.kde.org redirector for permanent links. > Anywhere needing a long life link to a particular repository, commit, > etc (like documentation) should be using these links and not anything > else. This is helpful. Thank you Ben! -- Alexander Potashev
Re: Context information needed for isolated words
El dissabte, 2 de maig de 2020, a les 13:11:55 CEST, Johan Ouwerkerk va escriure: > On Sat, May 2, 2020 at 12:36 PM Eloy Cuadra wrote: > > > > Hi, > > > > There is a widespread problem across many text strings to be translated: > > some isolated words are gender invariable in English, but not in many > > languages. > > > > For example, let's consider this case of a cascade menu: > > > > New > > > > Folder > > > > File > > > > What prevents you from arbitrarily re-naming a particular top level > entry? E.g. if you see "New", why not translate it as though it were > "Create" if that makes your translation work more naturally? > > I understand you'd want to stick as close as possible to the upstream > default, but languages being languages no doubt someone will point out > that verbs, too, could be conjugated differently depending on the > object. Or aspect, time, mood, actor, tense, whether or not it is > reflexive, medium, or otherwise. It could be that the verb might > change completely: i.e that creating a new folder somehow requires a > different translation of "create" than creating a new file would. > Which might mean that "New > File" is much more appropriate as a > starting point for *those* languages, because it avoids all the > verb-related pitfalls. > > English cares very little for any of that, so trying to account for it > in English might only serve to render it clumsy and awkward. > Conversely there are features which English is very particular about > like articles which many other languages don't bother with at all. > > All in all I think it is just easier if translation teams took some > liberties to get the point across rather than hoping for English to > become more like their native language. In particular this avoids most > of the need for complicated rules about "what words to use when". I don't think you understand what he is proposing. There's no request to change the English strings at all, just to add context to them. Please read https://techbase.kde.org/Development/Tutorials/Localization/i18n#Adding_Context_with_i18nc.28.29 Cheers, Albert > > Regards, > > - Johan >
Re: Context information needed for isolated words
>>> On 2 May 2020, at 08:12, Johan Ouwerkerk wrote: >> On Sat, May 2, 2020 at 12:36 PM Eloy Cuadra wrote: >> Hi, >> There is a widespread problem across many text strings to be translated: >> some isolated words are gender invariable in English, but not in many >> languages. >> For example, let's consider this case of a cascade menu: >> New >> Folder >> File > > What prevents you from arbitrarily re-naming a particular top level > entry? E.g. if you see "New", why not translate it as though it were > "Create" if that makes your translation work more naturally? > > I understand you'd want to stick as close as possible to the upstream > default, but languages being languages no doubt someone will point out > that verbs, too, could be conjugated differently depending on the > object. Or aspect, time, mood, actor, tense, whether or not it is > reflexive, medium, or otherwise. It could be that the verb might > change completely: i.e that creating a new folder somehow requires a > different translation of "create" than creating a new file would. > Which might mean that "New > File" is much more appropriate as a > starting point for *those* languages, because it avoids all the > verb-related pitfalls. > > English cares very little for any of that, so trying to account for it > in English might only serve to render it clumsy and awkward. > Conversely there are features which English is very particular about > like articles which many other languages don't bother with at all. > > All in all I think it is just easier if translation teams took some > liberties to get the point across rather than hoping for English to > become more like their native language. In particular this avoids most > of the need for complicated rules about "what words to use when". New is an adjective, if you translate it as a verb, in most places it will make no sense. Suppose the string "New" is used in these two situations: New File Folder Messages received: - Information regarding GitLab migration - Context information needed for isolated words [New] In the first case it's the action to create a new thing (file or folder), in the second case it indicates the second message is new. In some languages you may get away with using the same word, in some maybe not. "Nuevo" in Spanish makes sense in both cases, except that (as Eloy said) "Nuevo Carpeta" (new folder) has a gender mismatch. But I don't think there is *any* language where you can translate "New" as the verb "Create" and have that work in both cases. - Context information needed for isolated words [Create] ?? That's why the code needs to use i18nc, so that the two cases can be translated differently. -- Nicolás
Re: Context information needed for isolated words
El dissabte, 2 de maig de 2020, a les 16:08:26 CEST, Albert Astals Cid va escriure: > El dissabte, 2 de maig de 2020, a les 13:11:55 CEST, Johan Ouwerkerk va > escriure: > > On Sat, May 2, 2020 at 12:36 PM Eloy Cuadra wrote: > > > > > > Hi, > > > > > > There is a widespread problem across many text strings to be translated: > > > some isolated words are gender invariable in English, but not in many > > > languages. > > > > > > For example, let's consider this case of a cascade menu: > > > > > > New > > > > > > Folder > > > > > > File > > > > > > > What prevents you from arbitrarily re-naming a particular top level > > entry? E.g. if you see "New", why not translate it as though it were > > "Create" if that makes your translation work more naturally? > > > > I understand you'd want to stick as close as possible to the upstream > > default, but languages being languages no doubt someone will point out > > that verbs, too, could be conjugated differently depending on the > > object. Or aspect, time, mood, actor, tense, whether or not it is > > reflexive, medium, or otherwise. It could be that the verb might > > change completely: i.e that creating a new folder somehow requires a > > different translation of "create" than creating a new file would. > > Which might mean that "New > File" is much more appropriate as a > > starting point for *those* languages, because it avoids all the > > verb-related pitfalls. > > > > English cares very little for any of that, so trying to account for it > > in English might only serve to render it clumsy and awkward. > > Conversely there are features which English is very particular about > > like articles which many other languages don't bother with at all. > > > > All in all I think it is just easier if translation teams took some > > liberties to get the point across rather than hoping for English to > > become more like their native language. In particular this avoids most > > of the need for complicated rules about "what words to use when". > > I don't think you understand what he is proposing. > > There's no request to change the English strings at all, just to add context > to them. > > Please read > https://techbase.kde.org/Development/Tutorials/Localization/i18n#Adding_Context_with_i18nc.28.29 Or maybe i didn't read the email properly, he actually proposed to change some English strings. Please accept my apologies ^_^ Cheers, Albert > > Cheers, > Albert > > > > > Regards, > > > > - Johan > > > > > > >
Re: Context information needed for isolated words
On Samstag, 2. Mai 2020 14:46:12 CEST David Hurka wrote: > Yes, I am suggesting to forbid i18n() without c. For longer strings, the version without context is usually fine. This will only lead to people writing empty or nondescript comments, starting a habit that is worse than the current behaviour. If you really want to improve this on the tooling side, you could create a linter that is run by the CI and that warns for *short* i18n calls without context. Johannes
Re: Information regarding upcoming Gitlab Migration
Hi all, Sorry for late response, but project "cutehmi" fits into "sdk" category better than "applications" (technically it's a framework, but I guess "frameorks" is reserved for well integrated KDE Frameworks). Speaking generally on subject, categorization is always problematic. Categories often are fuzzy, they overlap, element can match more than one type/category/group at the same time and there are many criteria by which you could partition a set of elements. Maybe for future reference, it would be good if there was some explanation on how these groups are created. From what I can see large projects organized into subprojects have dedicated groups (e.g. plasma, kdevelop). There are groups based on project status (e.g. unmaintained, historical). Then we have a division, which seems to be based on use case from development applicability perspective (e.g. libraries, frameworks, sdk). Then we have applications divided into something like user interests (e.g. multimedia, games, office, education). Since you mention that project may belong to many groups it would be nice to clarify, if for example game-oriented library (which occupies "libraries") fits into "games" group as well or is "games" group reserved for end-user applications only. Regards Michał On 4/27/20 3:40 AM, Bhushan Shah wrote: [Please keep sysad...@kde.org list or bs...@kde.org in the CC for replies] Hello Community members, In view of upcoming Gitlab migration, we sysadmin team wants to share the recommended structuring for the repositories on Gitlab. We had multiple options, - Flat structure: In this option we would have everything under one single namespace/group: https://invent.kde.org/kde/knetwalk - Subgroups under top-level group: In this option we would have a groups under KDE namespace: https://invent.kde.org/kde/games/knetwalk - Groups at top level: In this option we would establish a series of groups at the top level, e.g. https://invent.kde.org/games/knetwalk We have discussed this with small but representative group of contributors or maintainers, and based on their suggestions, we recommend that we go with option 3. Having sub-groups at top level will allow us to, - Provides good visibility on all reviews, tasks and other items within the groups/modules we define - Provides improvements to discoverability of projects - Makes it possible for groups of projects to establish a group level task board should it fit their needs (for tracking a release for instance) - Makes the most semantic sense, as the ‘KDE’ top level group suggested in option 2 is duplicative considering the Gitlab instance is under kde.org. - The discoverability of projects is maximised, as there is no need to open the top level ‘KDE’ group before going into the subgroup. I've worked on draft "move" of the current set of the repositories in their respective subgroups at the repo-metadata project's branch [1]. You can browse the directory structure to get idea of how final structure on Gitlab would look like. If we don't have any objections we would like to implement this next week and move projects to https://invent.kde.org. Thanks! Bhushan for sysadmin team [1] https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
Re: Information regarding upcoming Gitlab Migration
On Sun, May 3, 2020 at 2:13 AM Michał Policht wrote: > > Hi all, Hi Michal, > > Sorry for late response, but project "cutehmi" fits into "sdk" category > better than "applications" (technically it's a framework, but I guess > "frameorks" is reserved for well integrated KDE Frameworks). I have now relocated CuteHMI within the proposed layout to SDK. The initial allocation to applications/ was done based on it's position at the moment in playground/base/ > > Speaking generally on subject, categorization is always problematic. > Categories often are fuzzy, they overlap, element can match more than > one type/category/group at the same time and there are many criteria by > which you could partition a set of elements. > > Maybe for future reference, it would be good if there was some > explanation on how these groups are created. From what I can see large > projects organized into subprojects have dedicated groups (e.g. plasma, > kdevelop). There are groups based on project status (e.g. unmaintained, > historical). Then we have a division, which seems to be based on use > case from development applicability perspective (e.g. libraries, > frameworks, sdk). Then we have applications divided into something like > user interests (e.g. multimedia, games, office, education). Since you > mention that project may belong to many groups it would be nice to > clarify, if for example game-oriented library (which occupies > "libraries") fits into "games" group as well or is "games" group > reserved for end-user applications only. There are no hard and fast rules for categorisation. Libraries that are only suitable for a specific purpose (like Games) could certainly go in Games. In general we'd expect maintainers to indicate a preference when requesting repositories. > > Regards > Michał Cheers, Ben > > > On 4/27/20 3:40 AM, Bhushan Shah wrote: > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for > > replies] > > > > Hello Community members, > > > > In view of upcoming Gitlab migration, we sysadmin team wants to share > > the recommended structuring for the repositories on Gitlab. > > > > We had multiple options, > > > > - Flat structure: In this option we would have everything under one > >single namespace/group: https://invent.kde.org/kde/knetwalk > > - Subgroups under top-level group: In this option we would have a groups > >under KDE namespace: https://invent.kde.org/kde/games/knetwalk > > - Groups at top level: In this option we would establish a series of > >groups at the top level, e.g. https://invent.kde.org/games/knetwalk > > > > We have discussed this with small but representative group of > > contributors or maintainers, and based on their suggestions, we > > recommend that we go with option 3. Having sub-groups at top level will > > allow us to, > > > > - Provides good visibility on all reviews, tasks and other items within > >the groups/modules we define > > - Provides improvements to discoverability of projects > > - Makes it possible for groups of projects to establish a group level > >task board should it fit their needs (for tracking a release for > >instance) > > - Makes the most semantic sense, as the ‘KDE’ top level group suggested > >in option 2 is duplicative considering the Gitlab instance is under > >kde.org. > > - The discoverability of projects is maximised, as there is no need to > >open the top level ‘KDE’ group before going into the subgroup. > > > > I've worked on draft "move" of the current set of the repositories in > > their respective subgroups at the repo-metadata project's branch [1]. > > You can browse the directory structure to get idea of how final > > structure on Gitlab would look like. > > > > If we don't have any objections we would like to implement this next > > week and move projects to https://invent.kde.org. > > > > Thanks! > > Bhushan for sysadmin team > > > > [1] > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent > > >
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 01, 2020 at 09:25:18AM -0400, Allen Winter wrote: > On Thursday, April 30, 2020 5:15:43 PM EDT Albert Astals Cid wrote: > > El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va > > escriure: > > > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić wrote: > > > > > > > > > We have made a big fuss in the past about having different projects > > > > > that do the same thing and now we'll have that but also we'll have > > > > > several projects with the same name? > > > > > It really feels off to me and I wonder if this is related to the move > > > > > to > > > > > gitlab. > > > > > > > > +1 to both sentiments - that projects should have different names and > > > > that > > > > this is a bit off topic for the gitlab migration. > > > > > > The projects *DO* have very different names. That *HAS NOT* changed. > > > To use the example Bhushan gave above, one is called Plasma Mobile > > > Dialer and the other one is called Maui Dialer. > > > > > > With the current git.kde.org setup, we have a flat namespace, so all > > > repositories if the name appears to be generic (as dialer is) have to > > > be namespaced by prefixing of the repository name. > > > > > > With Gitlab however we will now namespaces that group repositories, > > > making the prefixing unnecessary and as some projects have complained > > > about, duplicative. > > > > > > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your > > > path, which just looks silly. > > > > Am I the only person that just has all the repos on the same folder? I > > thought it was the common thing to do :? > > > I use kdesrc-build and I see the repos in a hierarchy. > In particular, I like frameworks in frameworks in kdepim in kde/pim > > I don't see that I'm setting any special "layout in a hierarchy" option in my > kdesrc-buildrc So it's been a few months since we had switched the default, but since it's clearly an invasive change, the way we addressed it was to make the flat hierarchy a default for new users (who use either of the 'quick config' schemes like kdesrc-build-setup or kdesrc-build --initial-setup), but to leave the built-in default unchanged. So in essence, existing kdesrc-build users (who had a folder-based layout by default unless they went out of their way to find the right option) saw no change, but new users would have that option pre-set for them in the config. Regards, - Michael Pyne
