Making WordPress.org

Opened 11 months ago

Last modified 10 months ago

#7132 new feature request

Automatic translation for exact strings

Reported by: marc4's profile Marc4 Owned by:
Milestone: Priority: normal
Component: Translate Site & Plugins Keywords:
Cc:

Description

When translating, there are certain words that are translated in one way or another depending on, for example, whether they are a noun or a verb, the context, etc. However, there are certain words, or combinations of words, that always, always, translate the same.

My suggestion is that just as there is a glossary for each local community, where the GTE suggest a translation, that there is a way in which they can define some words or phrases that always translate the same, so that they translate automatically. No suggestion.

I don't mean a word within a sentence, or combinations of words within a sentence. That would cause problems. I mean exact string matching. When the entire string to be translated is the same as the entire string that a GTE has marked as "automatically translatable", it is automatically translated to the text marked by the GTE.

This should be defined by the GTE of each local community.

Change History (6)

#1 @fierevere
11 months ago

This feature has been used before, not restricted to GTE, but to all approved stings.
Caused many problems for incorrectly, context-dependent and other somewhat fuzzy translations propagated across all projects.

It should be used with EXTREME caution, if at all.
For eveything else Translation Memory is fine.

#2 @Marc4
11 months ago

I understand that this could cause problems, that's why I say only exact strings. Machine translation should only be done if the string is exactly the same as the one defined by a GTE.

An example: Proudly powered by will always have the same translation within a local community. It would be a matter of making a list of such strings.

#3 @Marc4
11 months ago

It doesn't have to be a very large list, it can be just a few chains. The power here is in the repetition.

Translating just one of these strings, such as "https://wordpress.org/" would automatically translate more than 70,000 strings globally, multiplied by each of the 203 local communities, resulting in 14,210,000 strings translated in one click. With a probability of error, if I am not wrong, of 0%.

The string "https://wordpress.org/" would translate to whatever would have been established by each local community's GTE team, "https://ca.wordpress.org/", "https://es.wordpress.org/", etc.

Last edited 11 months ago by Marc4 (previous) (diff)

#4 @Marc4
11 months ago

These strings would be the same for all local communities and would be defined by global roles. For example, add that list of 10 or 20 strings in an area to which only one GTE role has access.

Once defined, new translations would add the strings defined for that local community. Perhaps there could also be a button to force old translations, prior to the current one (there should be some kind of delay here, because many requests would be executed).

Another way to do this would be to ask GTE to define these strings, but only executed from global roles. This would prevent that, for some strange reason, some GTE could change the translation several times, since it is assumed that these strings will always have the same translation, so they could be defined but not changed, unless the GTE team expressly requests it to the global roles with its argumentation.

#5 @pedromendonca
10 months ago

This has been discussed in the past. I agree that if it exist, shouldn't be the old propagation feature.
The only possibility I see is a curated list of common strings that MUST have a context, and should be very clear and not ambiguous.
Example:
"Are you sure you want to delete?" Context: confirmation after press delete button.
Later on, developers could pick some of these to use on their softwares.

#6 @Marc4
10 months ago

I think this list of strings could include cities and countries, since within a local community they will always have the same translation. This would save a lot of time and repetitive translations.

Note: See TracTickets for help on using tickets.