Improvement XWiki Translation

#1

Hello again!

Being engaged in translation, I meet often repeating lines of the text, as a rule it:
OK, Cancel, User, Name, First name, Log In, Log out, Server, Port, E-Mail, Permission, Right, +1000…

In addition, this text is repeated many times in additional modules, extensions, applications, etc.

It is possible to provide in XWiki a Global Glossary of frequently repeated string resources with the possibility of storing translation into other languages ​​(associative array, list).

Such a glossary will be enough to translate once (plus translate new lines when expanding the list in new versions of XWiki).
Then other developers should have access to this glossary at the program level and be sure to use reserved text in their development, and not place them again in their code, resources, etc. This approach is somewhat similar to the use of the XWiki icon set.

Thanks you!

0 Likes

#2

I don’t think that this is feature that exists in Weblate. Maybe @surli knows more about it?

One thing we wanted to do in the past was to implement this at the level of XWiki with a special syntax. Something like:

accessRights=Access Rights
welcometorightseditor=Welcome to the ${accessRights} editor. Choose a right entry to edit or add a new right entry:

But this isn’t implemented yet.

0 Likes

#3

Maybe I didn’t quite accurately describe my idea, this does not apply to the Weblate translation mechanism.
I’m talking about frequently repeated words, phrases, perhaps short sentences (examples I have cited) that are found in the XWiki project, its modules, extensions, and third-party applications.
Now in Weblate we have to do the same work on translating the same repeating word (phrase) in different modules of the system and third-party developments (I can bring screens later).
Therefore, there was a proposal to include in the project a module (class) with an associative array, in which key-value pairs of frequently encountered words (phrases) in different languages ​​will be pre-written. Only it is necessary to understand how to implement the possibility of translating into other languages ​​(here I’m not a helper for you, maybe these are several arrays or in general everything is stored in the database!).
To compile a list of frequently encountered words, you need to review your work and other developers, user interfaces, translation pages, hard-coded string resources (hard-coded strings are evil!), Etc.
For developers, a list of keys with their values ​​should be published. Knowing this list, developers should use it in their code.

Something like this:

btnCancel.Title = resource.getStringTranslated(STR_RES_CANCEL);

tableUsers.head[ID] = resource.getStringTranslated(STR_RES_ID);

If the translation of the string resource to the desired language (the language in the XWiki settings) is not found in the list, the string is output in ENG.

P.S.
In addition, such a list will lead to the unification (standardization) of the user interface in terms of string resources.

0 Likes

#4

I think we do that already. For example:

$services.localization.render('platform.index.documents')

But we never need a single word. Hence what I mentioned about the need to be able to include translations into translation with, for example:

accessRights=Access Rights
welcometorightseditor=Welcome to the ${accessRights} editor. Choose a right entry to edit or add a new right entry:
0 Likes

#5

And as a third-party developer developing a new extension of “MySuperApp” for XWiki, gets access to this accessRights resource in the code of its application? (in order not to create another resource “accessRights = Access Rights” in your application, which will have to be re-translated into Weblate)

0 Likes

#6

Yes.

See https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Tutorials/InternationalizingApplications/

0 Likes

#7

Why didn’t you give me a link right away, want to torture me? :wink: I write the opuses for kilometers here … :crazy_face:

Looks like I’m talking about this:

Using the static Resource Bundles

I checked the ApplicationResources_ru.properties file from xwiki-platform-legacy-oldcore-11.0.3.jar and found the following (see screenshot):
TranslateDuplication

This is just one example of the reuse of string resources for the word “Delete” (for different modules). I will find many such examples with other frequently repeated words (often used repeated resources)!

I correctly understand that the ApplicationResources_XX.properties file is generated using Weblate and assistants from different countries had to translate “Delete” into their own language about 19 times?

With the advent of the new application (module) using the word “Delete”, the developer will insert one or more string resources “Delete” to fit his needs … And the friendly team of translators will rush to Weblate to translate this word again? :boom:


And here is what I suggest:

delete=resource.getStringTranslated(STR_RES_DELETE)
core.shortcuts.view.delete=resource.getStringTranslated(STR_RES_DELETE)
core.menu.delete=resource.getStringTranslated(STR_RES_DELETE)
core.menu.space.delete=resource.getStringTranslated(STR_RES_DELETE)
and many, many etc

And then these string resources either should not fall into the translation systems at all (defined only in the application code), or should not be translated into the translation systems (then translators should know that such a string should not be translated).

And the STR_RES_DELETE resource has already been translated only once in different languages ​​and stored somewhere else (in the file, in the database - cool !!!)

Here!


P.S.
And it is not at all obligatory to insert the DELETE resource into other string resources, for example, long sentences. Let long sentences be translated by translation systems as Weblate.

Are you sure you want to delete this post? :sunglasses:

0 Likes

#8

I don’t think this is correct. Nobody has to translate “Delete” 19 times since I doubt there’s more than a few keys for just the word “delete” (there are 4 in practices). OTOH it’s very likely that translators have to translate different set of words of sentences in which the word “delete” appears, but that’s very different. The translation depends on the context.

Not that many, there are only 4 in practice in the main ApplicationResources.properties.

Actually if you want to use the same translation they you could use the same translation key. Now the reason we have different keys is probably because we may want to use different translations for different places.

For the record, this is exactly what I was suggesting with with the syntax above:

accessRights=Access Rights
welcometorightseditor=Welcome to the ${accessRights} editor. Choose a right entry to edit or add a new right entry:

I disagree with this. Every translation should be modifiable (overridable) by translators. This is why I prefer my suggestion above (ie reuse translation keys).

Now all is good but reusing translation keys doesn’t exist. We don’t have this syntax implemented. Are you proposing to implement it? :slight_smile:

Thanks

0 Likes

#9

So I gave it as an example! Different repeated simple words more (I’m sure)! And this I took only one jar!

So it’s not for me (the XWiki user) to reuse the translation key, developers should do this correctly so that I (the translation assistant) does not re-translate identical words (simple lines) in different resources!

For standard words and phrases in the user interface (have you forgotten about the unification of the user interface?), There is no need for different translations!
What is the translation of the standard UI words: Yes, No, OK, Cancel, Confirm, User, Login, Username, Password, + 100 similar on the Button is different when using the same words: in the Menu, in the headers of the Table Fields, in the label of the Input Fields, Selection buttons, etc.? And why the translation of such words should change in the UI of another application from a third-party developer!

No, I just ran into multiple translations of identical simple words (and phrases, and even sentences!) In different resources in the Weblate (this is where my post begins). Sometimes it happens like this: in position # 5, the word “Failed:” is translated as “Failed to execute:”, and in position # 105 it is translated as “Error:”. Just after 100 translation positions, the translator himself forgot how he translated it for the first time (and we are thinking about unification here;)

I thought that my proposal could be useful.


:footprints: left to translate and make screenshots of recurring translations in the Weblate :slight_smile:

0 Likes

#10

Sure, all ideas are good to discuss but in the end what matters is the implementation. Someone’s got to do it :slight_smile:

Thanks for the discussion.

1 Like

#11

Now I believe what would help even more is in-situ translations, i.e. translate direction from within XWiki, see https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/#HTranslationincontext

0 Likes

#12

Yes, I saw it, in the next branch I was given a link. Only it does not work yet?

Will this solution require an Internet connection?
My work system does not have access to the Internet due to security reasons. But I can work on a local wiki from home (for contributing).

0 Likes