Request for feedback about Apertium

Anyway these are just suggestions. Yes Google is often good, but any automatic translators will not know the context of use (thise can create confusion), or will not enforce a common terminology (so the same term may be translated differently from one message to another, or sometimes within the same message, depending on the structure of the sentence).

One bad thing that automatic translators have with English as the source, is that English is frequently confusive between nouns and verbs, and tends to remove many prepositions that would clarify the sense (as well the source punctuation is often forgotten, or English overuses the capitalization in many things that are actually not artwork title or brand names, so we get often some source messages that look much like the short newsfeeds on TV, with partial sentences and many unexpalined abreviations, sometimes a very specific jargon which is specific to the source project, and spoken by their programmers in their small teams, and it's not always evident to see what they mean).

So it's good if we can not just look at suggestions, but also being able to look at how they were understood in other languages (where they would be explained). That's why we not only see suggestions from automatic translators, but translators should be able (if they can) to read other submitted translations for other languages than just English (this can solve ambiguities).

But one thing should be clear: anything suggested in the right pane of the translate UI are jsut suggestions, hints. They may eventually accelerate edits by avoiding some common typos in terms that don't need to be corrected, but we still need to review them and correct them precisely. Just clicking a suggestion and validating is not acceptable, and we have to use the local search engine and, if there's some indication from the projects, their associated terminologies or guidelines in the Translating project portal, or in the language portal.

And if there are difficulties, we need to place hints or links to relevant discussions in the "/qqq" doc page (including when some message has a pending support request, here or on another channel), or may have some unsuspected consequence for some wiki (without forgetting that they may be specific to a specific target wiki or application instance). As well there are sometimes conflicts with their deployed target versions (here we may have messages accurate only for the latest development version, but still not for the currently deployed versions, and we have no visibility on when they will be deployed, possibly differently across sites or repositories)

If possible, the developers that change messages for a future version should create new message keys and keep the existing keys of messages for versions that are still active and supported). Unfortunately this is not always the case, and it's unpredictable when there's no clear documentation or warning (at least to signal to some target project that there may be some changes no longer working as expected on their current deployed version without preparing them).

So if it was possible, this wiki should be able to track branches/versions of a project for which any given message (or its /qqq documentation) is defined (the same message could belong to several branches). For now there's no such tracking: all versions are mixed in the same set, and we still don't have any lifecycle management for each project (just like we have for example in Git for branches, including those just for tests or for specific targets). The existing message keys could be reused for that, except that it's not easy to indicate multiple concurrent branches in the same key. The other solution would be to indicate branches by the key used to identify existing "message groups" (which already allow creating distinct but intersecting subsets of messages).

Finally, automatic translators are not equally good on all language pairs. One may be better or another, but there's also the local translation memory (for the target language, and for other related languages) that may help. In any case, all these useful suggestions have to be reviewed in the editor and not validated as is after just clicking on any one.