-
Notifications
You must be signed in to change notification settings - Fork 50
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
base: main
Are you sure you want to change the base?
Conversation
98662e8
to
4ea54e1
Compare
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
4ea54e1
to
48cf984
Compare
1bfe5ab
to
0302b81
Compare
add_to_serializer :post, :cooked, respect_plugin_enabled: false do | ||
return super() if cooked_hidden | ||
DiscourseTranslator::TranslatorHelper.translated_value(super(), object, scope) | ||
end |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
add_to_serializer :basic_topic, :fancy_title do | ||
DiscourseTranslator::TranslatorHelper.translated_value(object.fancy_title, object, scope) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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`; |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
translated = model.custom_fields[TRANSLATED_CUSTOM_FIELD] | ||
return original_value if (translated.blank? || translated[I18n.locale].blank?) | ||
|
||
translated[I18n.locale] |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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
add_to_serializer :post, :cooked, respect_plugin_enabled: false do | ||
return super() if cooked_hidden | ||
DiscourseTranslator::TranslatorHelper.translated_value(super(), object, scope) | ||
end |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
button.active svg { | |
button.active .d-icon { |
We usually target the icon class. Shouldn't active buttons be using the correct color in core?
@nattsw I pulled this branch locally (too excited to try it out!), but noticed that on
|
@pmusaraj oh, super weird that I never saw it! I'll add |
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