Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FEATURE: Translate full topics #199

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

FEATURE: Translate full topics #199

wants to merge 5 commits into from

Conversation

nattsw
Copy link
Contributor

@nattsw nattsw commented Jan 23, 2025

Needs #198 (first few commits are off that branch)

This feature is behind experimental_topic_translation and translates topics based on the language switcher selection.

topt.mp4

@nattsw nattsw force-pushed the translate-full-topics branch from 98662e8 to 4ea54e1 Compare January 24, 2025 03:51
nattsw added a commit to discourse/discourse that referenced this pull request Jan 24, 2025
As we start to translate more pages, we'll need a way for other sites to
link back to our translated topics.

This commit gives us the ability to use the "lang" URL param to define what
language a site should be in.

Related: discourse/discourse-translator#199
@nattsw nattsw force-pushed the translate-full-topics branch from 4ea54e1 to 48cf984 Compare January 24, 2025 03:59
@nattsw nattsw changed the base branch from main to always-use-body-to-detect-lang January 24, 2025 04:02
@nattsw nattsw changed the base branch from always-use-body-to-detect-lang to main January 24, 2025 04:02
@nattsw nattsw force-pushed the translate-full-topics branch from 1bfe5ab to 0302b81 Compare January 24, 2025 04:09
@nattsw nattsw marked this pull request as ready for review January 24, 2025 04:17
Comment on lines +51 to +54
add_to_serializer :post, :cooked, respect_plugin_enabled: false do
return super() if cooked_hidden
DiscourseTranslator::TranslatorHelper.translated_value(super(), object, scope)
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overriding a core's serializer attribute is going to be fragile to maintain long term. Perhaps we need an API extension in core?

Copy link
Contributor Author

@nattsw nattsw Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tgxworld We discussed this internally, can take a look at t/146193/5

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've read through the post but it doesn't address my concern about us overriding a core's serializer attribute from a plugin which is a form of monkey patching. Just to clarify, my concern here is not about us changing the value of the cooked attribute but the approach in which we are doing so.

Copy link
Contributor Author

@nattsw nattsw Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can revert to 2️⃣ in t/146193/1 if that helps. But the new 'problem' is that we'll be transmitting a lot more over the wire (translated_cooked+cooked) for something a user might not use (cooked)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have strong opinions on whether 1 or 2 is the better approach. What I am saying is that if we are going with 1, we probably want to introduce a plugin modifier/API in Discourse core that allows us to modify the value of the cooked attribute in the serializer safely.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense to have built-in protection for the existing add_to_serializer method so I'll see if I can keep it there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is experimental, I think we can add a note above the two add_to_serializer calls here, noting that we may/should refactor them before this can be production-ready.

Comment on lines +56 to +58
add_to_serializer :basic_topic, :fancy_title do
DiscourseTranslator::TranslatorHelper.translated_value(object.fancy_title, object, scope)
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one doesn't have an easy decorator unlike post.cooked.. 🤔

@action
async showOriginal() {
this.active = !this.active;
window.location.search = this.active ? "" : `show=original`;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible that there will be params already? Maybe it would be safer to append params?

https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/append

if (currentUser) {
if (siteSettings.experimental_topic_translation) {
api.renderInOutlet("topic-navigation", ShowOriginalContent);
} else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we should still check if(currentUser || SiteSetting.experimental_anon_language_switcher)

Copy link
Contributor Author

@nattsw nattsw Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean here? This feature will be available for anons also.

Do you mean we should disable it "if anon + no language switcher"? Ok, that makes sense.

Comment on lines +9 to +12
translated = model.custom_fields[TRANSLATED_CUSTOM_FIELD]
return original_value if (translated.blank? || translated[I18n.locale].blank?)

translated[I18n.locale]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if we are ready to solve this yet but if the translation is missing, do we display any indication in the interface for the user? It would be odd to the user if they request for a translation and we return the original one.

Copy link
Contributor Author

@nattsw nattsw Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will come in a subsequent commit. The idea is that in the future, all topics will be translated by default.

There needs to be a new outlet in core for the "indicator" on both the topic posts itself and the topic list view titles.

jancernik pushed a commit to jancernik/discourse that referenced this pull request Jan 24, 2025
As we start to translate more pages, we'll need a way for other sites to
link back to our translated topics.

This commit gives us the ability to use the "lang" URL param to define what
language a site should be in.

Related: discourse/discourse-translator#199
Comment on lines +51 to +54
add_to_serializer :post, :cooked, respect_plugin_enabled: false do
return super() if cooked_hidden
DiscourseTranslator::TranslatorHelper.translated_value(super(), object, scope)
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is experimental, I think we can add a note above the two add_to_serializer calls here, noting that we may/should refactor them before this can be production-ready.

}

.discourse-translator_toggle-original {
button.active svg {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
button.active svg {
button.active .d-icon {

We usually target the icon class. Shouldn't active buttons be using the correct color in core?

@pmusaraj
Copy link
Contributor

@nattsw I pulled this branch locally (too excited to try it out!), but noticed that on /latest, with Experimental topic translation enabled, I get a Rails error:

Attempted to access the non preloaded custom field 'translated_text' on the 'Topic' class. This is disallowed to prevent N+1 queries.

@nattsw
Copy link
Contributor Author

nattsw commented Jan 27, 2025

@pmusaraj oh, super weird that I never saw it! I'll add add_preloaded_topic_list_custom_field

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants