Ungoogled-chromium: Remove "Translate to ..." context menu entry and other UI

[zigboom]

Describe the bug
Right-click on any web page + "Translate to ____ (English in my setup)" does not work

To Reproduce
Steps to reproduce the behavior:

1. Open any web page
2. Right click anywhere on the page, choose "translate to ___ (English appears autmatically in my setup)
3. See error "This page could not be translated"

Expected behavior
The page should get translated

• OS/Platform and version:
• ungoogled-chromium version: 80.0.3987.149 / Windows 7 (64-bit)

[qvint]

Expected behavior:
The page shuld get translated

That contradicts the project goals. Duplicate of #781, #154.

[zigboom]

OK. Thanks

[TotalCaesar659]

Maybe it's better to remove that menu point. If somebody wants to translate, he can install an extension for it.

[Eloston]

@TotalCaesar659 Not a bad idea. We can remove translation UI in other places too.

[ObeseChicken]

Isn't the setting for translation in options defaulted to off? I do not get a translation menu. Right below spell check.

[zigboom]

Isn't the setting for translation in options defaulted to off? I do not get a translation menu. Right below spell check.

The setting "Offer to translate pages that aren't in a language you read" is off by default, but the right-click "Translate to ___" context menu is available.

[berkley4]

As someone who has been successfully building with translation enabled for the last couple of years, I would suggest that patches aimed at disabling/removing translation are kept separate in order to allow users to more easily re-enable it.

In particular, the 'all-add-trk-prefixes-to-possibly-evil-connections' patch contains a few required components that could easily be put into a separate patch. Others parts used to be patched out, but (on debian) this seems to no longer be the case, since '0014-disable-translation-lang-fetch' and 'disable-translate' are no longer included anywhere in debian/patches.

It ought to simply be a matter of deleting patches and adding a few sed commands to debian/rules (ie bypassing certain domain substitutions), to get translate to function.

Using an extension instead of native browser translation brings its own set of problems, eg privacy, performance concerns, plus wondering if whatever you've chosen is going to be maintained or not.

[Eloston]

I think @berkley4's use-case is a strong-enough reason not to remove the translation UI.

Another way we could deal with this issue is to move the translation API URLs to configurable values (in one of chrome://settings, chrome://flags, or CLI flags). If they're not present, we could somehow indicate to the user that the URLs need to be set.

[r3tner]

I for one would love to see a solution where the translation function can be enabled. As somebody who needs to translate websites a lot, this is the only thing holding me back from switching to your software.

Chromium is the only browser that can translate in-place. I understand the goals of this project, but I think translation is a special case, since no alternative is available elsewhere. Thanks.