Cannot customize some site texts

Support
1

I’m attempting to modify certain strings on the user preferences page. I navigated to Admin → Site Texts and searched for the relevant keys. However, I was unable to customize the specific text I was looking for as it told me there were no texts found.

image
image2192×1134 127 KB

I am reasonably certain that the key is valid, as it is defined here:

I then switched the target language to English but still yielded no results for user.username.short_instructions. Furthermore, I attempted to search for other strings such as user.username.title, user.preferences.title, and filters.latest.title, and no results either.

2 Likes
2

Very strange, I’m able to pull up the key

image
image1382×924 67.6 KB

If you right click and open the browser inspector, are there any errors in the console tab?

1 Like
3

image
image947×655 23.6 KB

It looks like there are no related errors, and based on the request results, it may be a backend issue.

Although I don’t believe the plugins I’ve installed have modified this particular area, I will attempt to remove all unofficial plugins later to see if that resolves the problem.

1 Like
4

You can temporarily disable customizations by using safe mode and see if that works

1 Like
5

I have some updates regarding this matter. I can now definitively confirm that the issue lies with the backend. While examining the code, I noticed a particular line:

To my surprise, executing I18n.exists?("js.user.username.short_instructions", :en) on my instance returns false.

image
image1428×213 14.5 KB

I manually removed this line of code, and I am now able to search for user.username.short_instructions

image
image683×495 26.5 KB

I am uncertain as to why I18n.exists?("js.user.username.short_instructions", :en) is returning false. I may investigate further to determine whether the problem is specific to my instance or a more general issue with Discourse.

6

Feels like a general issue you your Discourse instance.

sam@arch discourse % bin/rails c
Loading development environment (Rails 8.0.4)
[1] pry(main)> I18n.exists?("js.user.username.short_instructions", :en)
=> true

Particularly something around build. During build we parse all of this stuff and pop it in tables, somehow this did not happen yet in your instance.

Would recommend a console rebuild.

7

@sam, thank you for your response. I’ve deployed three Discourse instances using different methods, and all exhibit the same issue, leading me to believe it’s not an installation problem.

Upon re-examining my plugins, I discovered that one of them created a locale file (plugins/XXXX/config/locales/client.en.yml) with the following content:

en:
   js:

Deleting this file resolved the problem. After a brief investigation into the I18n implementation, I found that deep_merge is used to merge translations during loading:

    # File activesupport/lib/active_support/vendor/i18n-0.4.1/i18n/backend/simple.rb, line 31
31:         def store_translations(locale, data, options = {})
32:           locale = locale.to_sym
33:           translations[locale] ||= {}
34:           data = data.deep_symbolize_keys
35:           translations[locale].deep_merge!(data)
36:         end

The YAML above is parsed as:

{"en": {"js": null}}

This results in the deletion of the entire content under the en.js key after the merge. As a plugin developer, I understand that this issue stems from my own coding error, and I am fully responsible for it. However, I believe Discourse could benefit from additional checks to warn against such occurrences, especially considering that Discourse already has a design for inspecting locale files, as seen here.

4 Likes
8

Glad you found it!

I will ping the dev xp team so they are aware

4 Likes
10

Nice catch, thanks for updating us on the solution @pangbo.

We could definitely add a check here, although IIRC this checker is only used during RSpec tests. Would that have helped in your case?

Definitely open to having a runtime check for this null case, if we can find a good place to put it.

2 Likes
11

You are correct. I made an unwarranted assumption that these checks would execute at runtime. Upon searching the GitHub repository, it appears these checks are invoked solely within a rake task:

Adding checks here would not have preemptively identified the issue I encountered. Perhaps the most straightforward solution is to caution developers against this practice in the documentation :innocent:

2 Likes
13

What shall we do with this topic? Should we move it to Dev since it seems to be guidance for developers?