235c673fe8
This PR adds localized language names to settings. The language names
are localized in the frontend, not the backend, due to setting
initialization complexity.
This change affects these areas:
- `SiteSetting.available_locales`
- this "setting" is a lookup table to get language names. use
`languageNameLookup` service to get the name for a locale
- it returns an object that looks like the following, then gets
re-hydrated with client localized values when initializing the
`siteSettingService` in the frontend.
```
[
{"native_name":"اللغة العربية","value":"ar","name":"languages.ar.name"},
...
]
```
- `SiteSetting.default_locale`
- this is a single-value `enum` setting that has always been hardcoded.
This caused quite an issue as it is not initialized the same way as
other site settings in the yml file. It has always relied on reading
directly from a `names.yml` file to load native language names, thus
bypassing the need for I18n to be initialized from the backend. A new
locale_enum type has been introduced for this setting, and any future
settings.
- `SiteSetting.content_localization_supported_locales` - this is a
`enum_list` setting,
- enum_list is introduced, leveraging both `list` and `enum`
- theme translations
- site texts
- Wizard's default_locale choices
- it was set up from the backend using `LocaleSiteSetting.value`. This
proved problematic, as a Japanese user would be getting the locales in
English because the values are initialized using English even without
memoization
- therefore we're now initializing the choices in the frontend using
`available_locales` as defined above
- content localization meta data
- post language in the composer, localization composer, post history
modal, post language tooltip, language switcher
/t/151409
|
||
|---|---|---|
| .. | ||
| app | ||
| assets | ||
| config | ||
| db/migrate | ||
| jobs | ||
| lib | ||
| public/javascripts | ||
| spec | ||
| test/javascripts | ||
| vendor/holidays | ||
| .prettierignore | ||
| plugin.rb | ||
| README.md | ||
Discourse Calendar
Adds the ability to create a dynamic calendar in the first post of a topic.
Topic discussing the plugin itself can be found here: https://meta.discourse.org/t/discourse-calendar/97376
Customization
Events
discourse_post_event_event_will_startthis DiscourseEvent will be triggered one hour before an event startsdiscourse_post_event_event_startedthis DiscourseEvent will be triggered when an event startsdiscourse_post_event_event_endedthis DiscourseEvent will be triggered when an event ends
Custom Fields
Custom fields can be set in plugin settings. Once added a new form will appear on event UI. These custom fields are available when a plugin event is triggered.
Holidays
See an incorrect or missing holiday? Familiarize yourself with the holiday definition Syntax. Then make your updates in the vendor/holiday/definitions directory.
Generate updated holidays as follows.
cd vendor/holidays
# Generate holiday definitions
rake generate:definitions
Install the plugin and switch to the discourse root(not the plugin directory).
# Collect all holiday regions into assets/javascripts/lib/regions.js
bin/rails javascript:update_constants
Interactions with Other Plugins
You can use an element of this plugin with the Right Sidebar Blocks component. You'll want to ensure the desired route is enabled via the events calendar categories setting. In Right Sidebar Block's settings, the block name will be upcoming-events-list, and the params use this syntax, for example MMMM D, YYYY.
