DEV: Move logic for language support from post serializer into translators #180
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, the
post.can_translateattribute is determined in the post serializer itself, by checking if thedetected_languageof the post is translatable by the selected translator (e.g. Google, Microsoft)post.can_translatedetermines if the translate globe is visible on a post.This PR moves the check into the translator itself using the
language_supported?method, and the translator can determine if a language is translatable rather than doing the check outside the translator. This is needed because Discourse AI does not have the limitation of translatable languages, and the return result oflanguage_supported?will always be true, putting the check inside the post serializer has limitations since all translators will be required to define a SUPPORTED_LANG_MAPPING when there doesn't need to be one always.