Automatic Suggestions from Google Cloud Translation Advanced Returning Source Strings

[anubeon]

I'm running a project on hosted.weblate.org, and I am experiencing some issues using the Google Cloud Translation Advanced service for Automatic Suggests. Every automatic suggestion from the Google Cloud provider merely suggests the source string - for every language (e.g. "None" → "None"). In contrast, the Weblate Translation Memory provide is offering sensible suggestions.

I thought that the issue might be that my project's source language is English (Developer) and that Google might not have understood the en_devel language code, but I've also tried setting the translation service to use the secondary language, and set the secondary language at both project and component level to English (en) and Dutch (nl) and seen the same results.

Furthermore, I'm certain I had this working several months ago when I played around with the Automatic Translations Add-On. As evidenced by the below (and many other) suggestions that the add-on added in bulk to our projects in July. Note, I've confirmed that the add-on also n now returns source strings (not entirely unexpected as I suspect it uses the same underlying code?).

Does anybody have any idea what might be causing this?

I've toyed around with setting language aliases in the project workflow settings), but that didn't seem to fix the issue, and most of the language codes for the target languages (see below) look unproblematic to me as far as Google's language codes go.

Alas, as I'm using hosted.weblate.org, I don't have access to any detailed logging, so I can't see the details of any 'conversations' between Weblate and Google Cloud. :-(

Language codes taken from the component level overview:

• Dutch (nl)
• Finnish (fi)
• French (fr)
• German (de)
• Hungarian (hu)
• Italian (it)
• Spanish (es)
• Turkish (tr)
• English (en)
• English (Developer) (en_devel) ← might be problematic?
• Simplified Chinese (zh_Hans) ← might be problematic? Google uses zh-Hans (i.e. with a hyphen, not an underscore)
• Greek (el)
• Polish (pl)

[nijel]

The “evidence” it worked actually doesn't show that, because that is suggestion from the Weblate service, not from Google Translate. So it might have never worked…

The language mapping should work just fine, and languages should be mapped to service-specific codes correctly.

Is the machine translation on the Google side configured correctly? I barely recall somebody having messed up the setup there, making it behave weird.

We can also look at the project on Hosted Weblate. Can you please share a link to it? Either here or privately to care@weblate.org.

[anubeon]

"The “evidence” it worked actually doesn't show that, because that is suggestion from the Weblate service, not from Google Translate. So it might have never worked…"

My apologies, that was an oversight on my part. However, there is evidence of Google Cloud Translate Basic (API v2) having worked back in July 2025

I've done a search for signs of machine translated suggestions from Google Cloud Translate Advanced (API v3) using the below filter and came up empty, so I mustn't have enabled it back in July.

Is the machine translation on the Google side configured correctly? I barely recall somebody having messed up the setup there, making it behave weird.

I couldn't answer that with any authority, but the above would seem to suggest that Google Cloud Translate Basic (API v2) set-up was working at least working several months ago, and I haven't made any substantive changes in Google Cloud beyond creating the requisite service accounts, permissions/roles (see below), and keys to get up and running with Google Cloud Translate Advanced (API v3). Incidentally, I did set that up in July (even if I didn't use it).

We can also look at the project on Hosted Weblate. Can you please share a link to it? Either here or privately to [care@weblate.org](mailto:care@weblate.org).

I shall send the link via e-mail. :-)

[nijel]

After looking at the translation, I know why this happens:

• The project has configured the regex check flag (see https://docs.weblate.org/en/latest/user/checks.html#check-regex).
• It matches all the source strings.
• This makes Weblate mark the matched portion as placeable.
• Placeables are marked as non-translatable in machine translation calls.

The regex check was merely intended for single string checks rather than used in such a wide way. With the negative match pattern as you are using, it really can't work as expected with the machine translation.

[nijel]

Looking at this again, I don't think this is actually expected behavior from the regex flag. There is placeholder check that does this, and regex should not be exposed as non-translatable to allow things like you use it for.

#17697 changes the behavior.

[anubeon]

Thanks for looking into this @nijel.

I suppose our use of the regex flag in this instance is fairly atypical, giving our use case (i.e. embedded systems with limited fonts/character support). I'll try removing the flag for now, as I was essentially using it to identify and 'catch' translations with characters for which we don't already have a bitmap (we've other ways of doing that).

Thanks again.

[nijel]

The fix is now deployed on Hosted Weblate, so you can continue using your regex.

While I agree that your use case is not typical, there is no need to have overlapping behavior of regex and placeholder checks, so it definitely makes sense to distinguish the behavior in this regard.