Jump to content

Community

Grammatical case: not all languages behave like English


Recommended Posts

This isn't considered to be a bug so I've been asked to post in feedback instead.

Not all of us use English on our sites. And not all of our languages behave like English.

One of the problems for me is that the language string guidelines is used in the Guest Terms Bar ("See our Guidelines") but is also the title of the page Guidelines. This puts me in a difficult position because the word guidelines has different grammatical roles in the two situations. It does in English too (in the former it's a direct object); we just don't indicate the change in role anymore in English, unless using pronouns.

In my language (and in the Slavic languages, such as Russian, or in Finnish, or Hungarian, or occasionally in German ...) we have to mark the change in role by changing the form of the word. (We do in English too with pronouns: it's the difference between I and me, or he and him.)

Whether a change is made so that I can have a grammatically correct sentence seems to depend on my getting lots of support for this particular change. Well, I don't know about support, but I think it might at least be helpful if people from language backgrounds other than English can confirm that their languages too inflect for case. It's my hope that the unhelpful approach of "English does it this way and we won't accommodate changes if it's pointed out that we're forcing uses to have grammatically incorrect sentences" becomes sidelined if we can get people from different backgrounds to confirm that English's caseless system isn't universal.

@opentype Can you confirm that German uses cases and that IPS's occasional "like English" approach sometimes forces you to have ungrammatical sentences?

@hmikko Same request for Finnish.

@Upgradeovec Same request for Russian.

Anybody else? Feel free to make your voices heard!

Edited by Meddysong
Link to post
Share on other sites

Naturally we are aware that there are other languages than English, and that not all languages behave the same.

If you can point out specific issues you are facing, we can look at them specifically. For example, you said

Quote

One of the problems for me is that the language string guidelines is used in the Guest Terms Bar ("See our Guidelines") but is also the title of the page Guidelines. This puts me in a difficult position because the word guidelines has different grammatical roles in the two situations. It does in English too (in the former it's a direct object); we just don't indicate the change in role anymore in English, unless using pronouns.

What is your recommendation / suggestion / request exactly? Are you looking for a different language string for the guest terms bar vs the Guidelines page title?

Link to post
Share on other sites

Hello, Brandon. Yes, that's exactly what I requested in ticket 1016032, which was politely dismissed:

Quote

The language string guidelines appears in two different places: As the header of the Guidelines page and in the terms bar.

In some languages, including mine, the grammatical role is different in those two situations and so the word isn't translated the same. Please therefore keep the language string for one of these and introduce another string for the other situation, as you've done with Privacy Policy.

You already have this in place with /privacy/ and /terms/, where the language string in the title is separate to the one featuring in the guest terms bar.

And I don't doubt for one minute that you're aware that not all languages behave the same. But my request was politely dismissed this morning with the sentence "I'm not aware of any official language that would treat the context differently", so I thought I'd ask other people to confirm that their languages too use grammatical case.

Link to post
Share on other sites

It has been discussed a few times before. IPS should really try not to reuse the language strings. I have mentioned the "None" in picture alignment and "None" when selecting messages can have very different meaning in other languages. 

My wishlist for 5.x (I don't dream it will be addressed earlier):

1. Don't reuse language strings
2. Make the key more meaningful, i.e. use some form of strict structure, so we can easily understand which part we are translating based just on the key. 
3. Separate ACP and Public strings again. 

Link to post
Share on other sites

Hi @Meddysong. Thanks for summoning -)

Yep. We have a lot of points where we can't just translate using variables. In that cases, we need to expand some key to 10+ keys for providing a right translation.

Some examples:

email_new_content_unapproved_guest  - %s (Guest) has posted %s requiring approval, - 'posted %s' may contain very different content types and word 'posted' should know what is %s
stream_blurb_in_containers - %s in %s - same story. 'in' should depend on the type of the second param

So in that examples, I mean the problem about using 'meta'-keys - keys, which includes other keys. If you can create 20 same strings (for English) for each type of content contain - it will be much better than your current savings. All languages are very different. So you just need to make keys as much simpler as possible to make localization easier (and thanks for ordering ability).

We made high-quality translations from native speakers with specialized education to this languages: cs_CS, de_DE, en_EN, es_ES, fr_FR, it_IT, ja_JP, ko_KO, pl_PL, ru_RU, th_TH, tr_TR, zh_TW_CHT, zu_ZU.

Some issues I understand very hard, like that (and moreover - I don't know English well):
 f4321-clip-79kb.thumb.png.7ad1c02bbe1a923e84a8925fb84c0d13.png07b9c-clip-57kb.jpg.b036f8b9ec97ce6a218d1f1a06761a8e.jpg

So, I can ask our Loc&Doc Department for creating a full list of problems with current l10n work, if you want to herd it and their work wouldn't ignore.

 

Link to post
Share on other sites
21 minutes ago, Upgradeovec said:

So, I can ask our Loc&Doc Department for creating a full list of problems with current l10n work, if you want to herd it and their work wouldn't ignore.

No, I think that would be too much work to expect of IPS, but thank you all the same. But it's a shame that such an easy request, bringing this page into alignment with its siblings, is just dismissed. It doesn't look good at all if I direct people to read our guidelines but have the word spelled incorrectly in the heading, does it? So I'd better spell it wrong in the guest terms bar instead ...

What I really wanted from you is to say "Yes, the word for X changes" if I use it in the following situations: "X is ... ", "Hello, X!", "I posted an X", "... with an X", "... to an X" and so on. Your language is a lot more mainstream than mine so harder to dismiss! ? 

Link to post
Share on other sites

Oh those translations... ?

I've had to make many funny translations to make sentences seem OK. Back to 3.x.x I even reported some in Bug Tracker but only couple got "fixed".
My language problem is that Suite uses same phrases in many places. But in one sentence it sounds good but in other it sounds very weird. Let's take an example: When someone adds images to the gallery I got an email. It says that someone added a new image. In English, you can use "new images" as "new image" but in Estonian theres "uue pildi" and "uued pildid". image=pilt, images=pildid. Phrase image and images are changing when theres multiple but in Estonian changing only one word isn't enough. And I can't translate that "new" with changing phrase because images and image are used in other places as well. Theres many other examples as well. Thats why I think theres should be strings for Activity, Gallery, Topics separately.

Second example is English words "on", "in" "at" etc. We have no prepositions in Estonian. There used to be most online counter where were language string "On" and there come date after it. In Estonian you can't replace it with nothing because we don't have anything to replace it with. And word "in" - "in topic", "in album". We change the word topic. Like topic=teema but "in topic" is "teemas". We change the ending of a word not use preposition. But this phrase "topic" is used in many sentences and I cant change it to "teemas" because it will change the meaning of a sentence in somewhere else.

Estonia have 14 cases and no prepositions, Finland has 15 cases and no prepositions, English has 2 cases and have prepositions, Germany has 4 cases and have prepositions, Spain has 0 cases and has prepositions. Languages are different. ?

But I'm already used with those language differences. Have managed to translate them somehow (only new image email is still weird). But always worried if some upgrades are available, hoping upgrading won't change something.

Link to post
Share on other sites
2 hours ago, hmikko said:

Estonia have 14 cases and no prepositions, Finland has 15 cases and no prepositions

Thank you! Mine has two cases and prepositions but in the context of "guidelines", the first instance requires my first case whilst the second needs one to mark the direct object.

I too have managed to cope usually with little tricks. That's not possible for me in this case though.

(I imagine you have the same problem with the word "guidelines" when it's used as a title and when it appears in "see our guidelines".)

Link to post
Share on other sites

The most annoying thing preventing me using Pages is the missing grammatical cases. There are a lot of languages that do have cases, see some examples https://en.wikipedia.org/wiki/Grammatical_case#Examples The language settings in the database are just not enough for those languages:

screenshot-localhost-2018_08_08-13-06-54.thumb.png.7f21354a2b978d5bbbf36d8da6eb8c6d.png

There are much more different forms that are required to create grammatically correct sentences in those languages. Ideally there should be a matrix for case/plural form like below where all word's forms can be entered and then used in translation strings e. g. like %s[3:1] that would mean 3rd case, singular. 

screenshot-en.wikipedia.org-2018_08_08-13-10-29.png.41571a442f86b1e7d1ca571caede5f5c.png

 

Link to post
Share on other sites
On 7/27/2018 at 5:49 PM, Upgradeovec said:

Some examples:

email_new_content_unapproved_guest  - %s (Guest) has posted %s requiring approval, - 'posted %s' may contain very different content types and word 'posted' should know what is %s
stream_blurb_in_containers - %s in %s - same story. 'in' should depend on the type of the second param

There is already replacement in phrases for the plural like {# [1:reply][?:replies]}. It would be perfect if this would work in language translation as well. In languages with dual, trial, or paucal numbers (Slavic and Baltic) we need however some more forms than only singular/plural. 

Link to post
Share on other sites
2 minutes ago, Sonya* said:

In languages with dual, trial, or paucal numbers (Slavic and Baltic) we need however some more forms than only singular/plural.

That's possible, Sonja. @Mark developed this pluralization system to be adaptable for precisely this scenario, his example being Slovak and how the noun changes depending on the number: 

(Has it really been five years since the blogs introducing IPS4?! The years have whizzed by!)

Link to post
Share on other sites
1 minute ago, Meddysong said:

That's possible, Sonja. @Mark developed this pluralization system to be adaptable for precisely this scenario, his example being Slovak and how the noun changes depending on the number: 

(Has it really been five years since the blogs introducing IPS4?! The years have whizzed by!)

Does it work in translation as well? :unsure: I know, I can use replacements in template, but what about translation strings? I have just tried it out and it outputs the replacement as is.

Link to post
Share on other sites

Yes, this is for translation.

Lithuanian reply/replies, for example, looks like this:

Quote

1 atsakymas

2-9 atsakymai

10-20 atsakymų

21 atsakymas

22-29 atsakymai

30 atsakymų

31 atsakymas

32-39 atsakymai

And that should be rendered within the system by:

{# [%1:atsakymas][10-20,%0:atsakymų][?:atsakymai]}

 

Link to post
Share on other sites
10 minutes ago, Meddysong said:

That's possible, Sonja. @Mark developed this pluralization system to be adaptable for precisely this scenario, his example being Slovak and how the noun changes depending on the number: 

I guess you talk about general translations on forums etc.. Sonya about specific cases in the pages database. This has own rules (see screenshot above).

Link to post
Share on other sites
4 hours ago, Ramsesx said:

I guess you talk about general translations on forums etc.. Sonya about specific cases in the pages database. This has own rules (see screenshot above).

Until now I missed the first post! Yes, that does a good job of demonstrating why there's a problem.

Pages handles things differently, unfortunately. There are circumstances where my cases aren't quite correct. For example, I write the indefinite article in its accusative form because that's how it would usually be used (it appears usually as "X added + [indefinite article] to Y") but sometimes it needs to be in another case. There's not much you can do about that, unfortunately.

Link to post
Share on other sites
19 hours ago, Sonya* said:

There is already replacement in phrases for the plural like {# [1:reply][?:replies]}. It would be perfect if this would work in language translation as well. In languages with dual, trial, or paucal numbers (Slavic and Baltic) we need however some more forms than only singular/plural. 

 

On 7/27/2018 at 6:49 PM, Upgradeovec said:

Some examples:

email_new_content_unapproved_guest  - %s (Guest) has posted %s requiring approval, - 'posted %s' may contain very different content types and word 'posted' should know what is %s

In my example, I mean 'posted' should change depend on the second '%s' content type. Not on a containing number.

And one more note about replacements. If we imagine a clear understanding the type of content in '%s' (forum comment, for example) in some languages we need to change the word before replacement ('posted' in the example) which should change for 1 item or more than 1 item. Any way to do it?

Anyway. l10n & l18n is the deep rabbit hole. IPS can't resolve all these problems. I just want to make some easy rules, which can help us to make changes easier. For example, not include any localization strings inside other localization strings. Better to create many of the same strings, than create one, which generated one from another.

Edited by Upgradeovec
Link to post
Share on other sites
1 minute ago, Upgradeovec said:

 

In my example, I mean 'posted' should change depend on the second '%s' content type. Not on a containing number.

And to make it more complex: in some languages verb endings depend on the gender of the person who has done something (e. g. posted or commented) and on the number of the persons who have done it, e. g. French:

passe-compose-auxiliary-verb-etre-endings.png.887b308365614275f88554c762feadb5.png

 

Link to post
Share on other sites
1 minute ago, Sonya* said:

And to make it more complex: in some languages verb endings depend on the gender of the person who has done something (e. g. posted or commented) and on the number of the persons who have done it, e. g. French:

passe-compose-auxiliary-verb-etre-endings.png.887b308365614275f88554c762feadb5.png

 

:laugh: yep) it's too deeper)) I think this is the main reason in most part of the web for using 'user', 'person', 'author' and other gender-neutral impersonal words)

But! Facebook solves this gender depending words (not exactly correct, but not bad)! I think IPS should solve this too! Because they compared In BD topic themselves with FB, YouTube, and other giants...)

Link to post
Share on other sites
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy