IPS Localization / Some strings can't be localized properly

[Numbered]

Hello friends! Our localizators have notified us of some issues connected with the IPS strings they need to localize. The details are below:

Quote

 

Many of the strings we've received within the forum localization task are split into several parts and need to be fixed. The thing is, all languages are different, they have different grammar rules, word order, noun cases, and so on, that's why we can't split strings based on English rules only. Please remember that when it comes to localization, we can't localize sentences split into several strings or with some parts/words missing.

The string [%s has posted %s, %s, for %s]  (from word keys of calendar app: "email_new_calevent_plain", "email_new_calevent", "email_new_calevent_guest") is a typical example of what can't be localized properly.

• First of all, there are 4 placeholders that look exactly the same and make no sense for translators. It's not clear what values will be used instead of these four placeholders and translators won't be able to change the word order because the placeholders are identical.
• Moreover, one of the placeholders in string [%s has posted %s, %s, for %s] is replaced with the noun [a calendar event] (word key "__indefart_calendar_event") which is totally ok for English but is totally unacceptable for Russian, Polish, and Czech (in particular) because these languages use noun cases. When regional translators see the string [a calendar event] they localize it in the nominative case because they are unaware of the fact this string will be used as a part of another string.

To sum it up, the string [%s has posted %s, %s, for %s] must look like [%(username)s has posted a calendar event named "%(eventname)s" on %(datetime)s]. In this sentence, translators can clearly see the structure, change the word order if necessary, understand the meaning of the placeholders, and so on. If you need a similar sentence saying that the user has posted not a calendar event but smth else, it's necessary to create a separate full sentence for that case.

 

That was only one example describing some issues localizators may face when working with "broken" strings. It would be great if you could keep the above listed tips in mind when adding new phrases to the project in the future so that we don't need to change anything in your code. Please let me know if you need more information.

[Meddysong]

I agree that it's difficult to translate when you don't know what the string %s is. I've been caught out myself when the sentence has needed something with a certain grammatical case but the %s needs to be in another case when used on its own. I'm not sure what the solution is, other than translating every sentence. I have to accept with my site that I have sentences which aren't grammatically correct. I don't think it's possible to create a system which will work for all languages without simply translating whole sentences.

Your translators might not be be aware that it's possible to change the word order where needed: https://invisionpower.com/4guides/themes-and-customizations/languages-and-localization_326/replacements-in-phrases-r122/

 

[jair101]

15 minutes ago, Meddysong said:

I have to accept with my site that I have sentences which aren't grammatically correct.

Sadly, I came to the same conclusion. I think for 5.x IPS need to actively research language specifics, because the current language system is very barebone and can't acommodate the richness of all languages. Time will be much better spent by proper understanding of what all foreign languages require then developing gimmicks like the visual language editor. 

Ditching all these patchwork sentences and properly abstracting each sentence in a separate language bit will be a good start. %s and %d should be left only for string and numeric variables, they shouldn't be used as word constructors of complete sentences. 

[Meddysong]

I don't think it's possible to accommodate everything. You could engage with the finest linguistic minds on the planet and the only conclusion would be that there's so much variety out there that you simply can't avoid translating everything. No shortcuts, otherwise you force a certain (maybe significant) number of your users to have ungrammatical forms on their sites.

[Cyboman]

Another problem is, that if you do a lot of copy and paste during translations, you might oversee some %s variables left or you add some %s accidentially so you get "%s duplicates" which display double the value or some other value. Unfortunately you can't search for "%s" and neither for "%s, %s" in the language strings. Hence if I try to find the faulty language string entry, I have to go manually through the whole database, which in my case, already has 15.000 entries! That's not a perfect solution.

[jair101]

I understand that it is not possible to create a perfect language system, but a little bit of consideration will go a long way.

For example in english many verbs and nouns are written the same way (Reply, Vote, etc can both be a verb and noun). This is not common in many other languages and nouns and verbs sound and are written differently. So lets say I am translating the string "Reply" in ACP. There is no way for me to recognize if it is the verb or noun. It would have been so much better if this information is added in the language key, it might be reply_verb or reply_noun, etc. 

In fact, the language keys can help the translators A LOT if just a little bit of care and simple convention is used when creating them. I had to find based on experience that in the current system strings starting with p_ represent permissions, which I don't need to display on the frontend, same for menu_ and so on. A simple convention could be like this:

app_module_location_context_type, which will result in a language key like this: forums_reputation_profile_overview_noun. Even without the string itself I realize that I am translating the place in profile where total reputation is displayed. Instead right now we have something like rep_tot, which can be placed pretty much anywhere. 

This is just a very basic idea at the top of my head, but basically language keys can be used to provide important information about the context of the phrase and not be something barely more then a random gibberish.

I agree that the total richness of all languages is impossible to capture, but this shouldn't be an excuse to not try to improve the current language system. IPS prides itself on being enterprise ready and used by very large companies. Imagine how their customers would feel if their community interface sounds like a native american from a stupid western movie, which is essentially how our translated communities sound like today in our languages. 

And, please, please, please, in the next version separate ACP strings from Frontend again.

[Meddysong]

Yep, you're totally correct. I've often had to leave entries blank because I've not been sure whether they refer to verbs or nouns.

3 hours ago, jair101 said:

And, please, please, please, in the next version separate ACP strings from Frontend again.

This would be fantastic. I think most of us are happy to use English in the ACP and would see translating those strings as a colossal waste of time.

[jair101]

I want to point out another important issue related to translation. We can align attached pictures with left, right and NONE:

 

We can also select all or NONE personal messages:

 

While in English it makes perfect sense to use the word "none" in both situations, thus the same string is used, in other languages it is very much dependent on context. And the context of aligning pictures is very different then selection of rows. So please, don't skimp on language strings and even if in english you can use the same word consider that in other languages it is not possible. 

In my language it is practically impossible for me to translate "none" in a way suitable for both situations. 

 

[Joel R]

On 3/30/2017 at 11:52 AM, jair101 said:

I want to point out another important issue related to translation. We can align attached pictures with left, right and NONE:

 

We can also select all or NONE personal messages:

 

While in English it makes perfect sense to use the word "none" in both situations, thus the same string is used, in other languages it is very much dependent on context. And the context of aligning pictures is very different then selection of rows. So please, don't skimp on language strings and even if in english you can use the same word consider that in other languages it is not possible. 

In my language it is practically impossible for me to translate "none" in a way suitable for both situations. 

 

Just curious, how would you translate "not any?". That should be the long form English in both cases.

[jair101]

1 hour ago, Joel R said:

Just curious, how would you translate "not any?". That should be the long form English in both cases.

It will be tricky to explain to you in English, why I cannot use the English logic in this case  Lets make a longer translation to include the context somehow, because there is no universal word suitable for both cases in my language. For the alignment "none" imagine that literal translation is "Without alignment"  and "No rows" for the second case. Even if you remove the context clarifying word you will have "without" and "no". Imagine if the alignment case has "left", "right" and "no" as options. And the selection case has "all" and "without" as options.  Doesn't sound good at all.