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
Prevent renaming lesson and lesson groups keys in scripts that are stable and i18n #36219
Conversation
…le and in i18n list
@@ -2035,13 +2035,11 @@ class SummarizeVisibleAfterScriptTests < ActiveSupport::TestCase | |||
assert_equal 'Expect all lesson groups to have display names. The following lesson group does not have a display name: content1', raise.message | |||
end | |||
|
|||
test 'raises error if lesson group key already exists and try to change the display name' do |
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 looks really weird. I deleted an old test and added a new tests. They are not really connected.
… changing the key
dashboard/app/models/lesson_group.rb
Outdated
@@ -92,6 +86,12 @@ def self.add_lesson_groups(raw_lesson_groups, script, new_suffix, editor_experim | |||
end | |||
end | |||
|
|||
def self.prevent_changing_stable_i18n_key(script, raw_lesson_group) | |||
if script.is_stable && ScriptConstants.i18n?(script.name) && !(I18n.t "data.script.name.#{script.name}.lesson_groups").keys.map(&:to_s).include?(raw_lesson_group[:key]) |
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.
same as above: can use ... #{raw_lesson_group[:key]}
instead of .keys.map...include?
?
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.
even better, would it be possible to DRY this up a bit? I think a Policy Object might be appropriate here
@@ -1021,7 +1021,7 @@ def self.base_name(name) | |||
def copy_and_write_i18n(new_name) | |||
scripts_yml = File.expand_path('config/locales/scripts.en.yml') | |||
i18n = File.exist?(scripts_yml) ? YAML.load_file(scripts_yml) : {} | |||
i18n.deep_merge!(summarize_i18n_for_copy(new_name)) {|_, old, _| old} | |||
i18n.deep_merge!(summarize_i18n_for_copy(new_name)) |
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.
why are we removing the block passed to deep_merge!
here? I'm not saying it's wrong, but it looks a bit tricky and related to a thing I need to do to the summarize methods next so hoping to learn something.
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.
So removing the {|_, old, _| old} will make it so if there is the same key in both i18n and summarize_i18n_for_copy it will default to the one in summarize_i18n_for_copy. That seemed to me like what we would want but you know this area of the code better than I do so maybe thats incorrect?
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.
My concern was that this change might expose some bug like the one we saw where the i18n system did not immediately reflect a new value after one was written, i.e. the scripts.en.yml file would be guaranteed to be fresh but whatever you got from summarize_i18n_for_copy might not be because it calls I18n.t
.
I dug in github commit history and ended up with this gem: 4cb8b73 the commit description points to 2 other commits which flip flop between using or not using this block, both of which were merged to staging back in 2014 without a PR and without comment! It really was the wild west back then :-)
So based on all of that I don't want to give any special credit to the way the code was, although it still needs a small amount of credit since we know that it's been working for about 4 years.
I would say, go ahead and make this change. If i am reading correctly, this code line won't have any effect most of the time, and I think your change may actually fix a problem by updating scripts.en.yml to actually properly copy of all the i18n when we copy a script. we can verify that when we focus on script copy in December or January.
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 think I have anything to add beyond Dave's review.
Background
For a long time we have used the the name of the lesson as both the key for the lesson and then display name. This leads to challenges. One example of these challenges is in translation. In order to keep the key consistent for translations we don't want levelbuilders to change the name in the Script DSL. Instead an engineer needs to update the display name in scripts.en.yml.
Change
In order to get away from using the name as both the key and the value we are going to add a separate key value to lessons. This is going to take a couple steps:
Testing
-Add tests to check that you can't add new lesson group or lesson to a script that is stable and i18n
-Add test to check you can't change the key of a lesson in a stable and i18n
-Add test to make sure we don't have a blank display name provided by levelbuilder in dsl
-Add test to make sure that changing the display name of a lesson updates correctly in scripts.en.yml