Details
Description
- Update `plugin_actions` to support translating the `name` field using language from the plugin. The plugin can then set an action that will represent the language definition to use (e.g. "SupportManagerPlugin.nav_primary_client.main")
- Whenever plugin actions are retrieved, load up and instantiate the associated plugin
- Call $this->_(..plugin definition..) on the plugin action definition to translate it
- The navigation cache may need to be reset whenever someone changes their language or a plugin is installed/upgraded (which may or may not already take place)
Note: The language for the actions are assumed to come from /plugins/plugin_name/language/en_us/plugin_name_plugin.php. If not set here then it will use the name of the plugin as given
When a plugin (e.g. Support Manger) is installed, it can register navigation links. Currently, these navigation links are translated definitions of the current language. Since these definitions are saved in the database, they are not translated into the admin/client's language.
e.g. An admin can install the Support Manager plugin (default lang = en_us). If a client uses a different default language, they will always see the en_us version of the translation for the Support Manager navigation links.
We may want to consider saving the navigation definition term rather than it's definition translation, and allow for the navigation to load up the plugin's language file(s) to translate the definition on the fly to better support multi-language navigation links.
Issue Links
- relates to
-
CORE-2987
Support Manager: Use language keys for plugin actions
-
- Closed
-
-
CORE-2991
Order: Use language keys for plugin actions
-
- Closed
-
-
CORE-2992
Mass Mailer: Use language keys for plugin actions
-
- Closed
-
-
CORE-2993
Billing Overview: Use language keys for plugin actions
-
- Closed
-
-
CORE-2994
Blesta Reseller: Use language keys for plugin actions
-
- Closed
-
-
CORE-2995
Client Documents: Use language keys for plugin actions
-
- Closed
-
-
CORE-2996
Download Manager: Use language keys for plugin actions
-
- Closed
-
-
CORE-2997
Feed Reader: Use language keys for plugin actions
-
- Closed
-
-
CORE-2998
Reassign Pricing: Use language keys for plugin actions
-
- Closed
-
-
CORE-2999
System Overview: Use language keys for plugin actions
-
- Closed
-
-
CORE-3000
System Status: Use language keys for plugin actions
-
- Closed
-
Show 6 more links (6 relates to)
Activity
Tyson Phillips (Inactive)
created issue -
Paul Phillips
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | Short Term [ 10800 ] |
Tyson Phillips (Inactive)
made changes -
| Assignee | Cody Phillips [ cody ] | Tyson Phillips [ tyson ] |
Tyson Phillips (Inactive)
made changes -
| Description |
When a plugin (e.g. Support Manger) is installed, it can register navigation links. Currently, these navigation links are translated definitions of the current language. Since these definitions are saved in the database, they are not translated into the admin/client's language.
e.g. An admin can install the Support Manager plugin (default lang = en_us). If a client uses a different default language, they will always see the en_us version of the translation for the Support Manager navigation links. We may want to consider saving the navigation definition term rather than it's definition translation, and allow for the navigation to load up the plugin's language file(s) to translate the definition on the fly to better support multi-language navigation links. |
# Update `plugin_actions` to support a new `definition` field (varchar 255) that will represent the language definition to use (e.g. "SupportManagerPlugin.nav_primary_client.main") # The `name` field set by plugins, and saved in `plugin_actions`.`name` will be deprecated #* It will be replaced by the translated version of `definition` by the PluginManager model # Whenever plugin actions are retrieved, load up and instantiate the associated plugin #* Call $this->_(..plugin definition..) on the plugin action definition to translate it * The navigation cache may need to be reset whenever someone changes their language or a plugin is installed/upgraded (which may or may not already take place) ---- When a plugin (e.g. Support Manger) is installed, it can register navigation links. Currently, these navigation links are translated definitions of the current language. Since these definitions are saved in the database, they are not translated into the admin/client's language. e.g. An admin can install the Support Manager plugin (default lang = en_us). If a client uses a different default language, they will always see the en_us version of the translation for the Support Manager navigation links. We may want to consider saving the navigation definition term rather than it's definition translation, and allow for the navigation to load up the plugin's language file(s) to translate the definition on the fly to better support multi-language navigation links. |
Tyson Phillips (Inactive)
made changes -
| Story Points | 3 |
Tyson Phillips (Inactive)
made changes -
| Sprint | 4.5.0 Sprint 1 [ 66 ] |
Tyson Phillips (Inactive)
made changes -
| Rank | Ranked higher |
| Assignee | Tyson Phillips [ tyson ] | Jonathan Reissmueller [ jonathan ] |
Automated transition triggered when Jonathan Reissmueller created a branch in Stash -
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Remaining Estimate | 0 minutes [ 0 ] | |
| Time Spent | 1 hour, 3 minutes [ 3780 ] | |
| Worklog Id | 11623 [ 11623 ] |
Automated transition triggered when Jonathan Reissmueller created pull request #555 in Stash -
| Status | In Progress [ 3 ] | In Review [ 5 ] |
| Resolution | Fixed [ 1 ] |
Tyson Phillips (Inactive)
made changes -
| Fix Version/s | 4.5.0-b1 [ 11108 ] | |
| Fix Version/s | Short Term [ 10800 ] |
| Time Spent | 1 hour, 3 minutes [ 3780 ] | 1 hour, 19 minutes [ 4740 ] |
| Worklog Id | 11643 [ 11643 ] |
Tyson Phillips (Inactive)
made changes -
| Description |
# Update `plugin_actions` to support a new `definition` field (varchar 255) that will represent the language definition to use (e.g. "SupportManagerPlugin.nav_primary_client.main") # The `name` field set by plugins, and saved in `plugin_actions`.`name` will be deprecated #* It will be replaced by the translated version of `definition` by the PluginManager model # Whenever plugin actions are retrieved, load up and instantiate the associated plugin #* Call $this->_(..plugin definition..) on the plugin action definition to translate it * The navigation cache may need to be reset whenever someone changes their language or a plugin is installed/upgraded (which may or may not already take place) ---- When a plugin (e.g. Support Manger) is installed, it can register navigation links. Currently, these navigation links are translated definitions of the current language. Since these definitions are saved in the database, they are not translated into the admin/client's language. e.g. An admin can install the Support Manager plugin (default lang = en_us). If a client uses a different default language, they will always see the en_us version of the translation for the Support Manager navigation links. We may want to consider saving the navigation definition term rather than it's definition translation, and allow for the navigation to load up the plugin's language file(s) to translate the definition on the fly to better support multi-language navigation links. |
# Update `plugin_actions` to support translating the `name` field using language from the plugin. The plugin can then set an action that will represent the language definition to use (e.g. "SupportManagerPlugin.nav_primary_client.main")
# Whenever plugin actions are retrieved, load up and instantiate the associated plugin #* Call $this->_(..plugin definition..) on the plugin action definition to translate it * The navigation cache may need to be reset whenever someone changes their language or a plugin is installed/upgraded (which may or may not already take place) ---- When a plugin (e.g. Support Manger) is installed, it can register navigation links. Currently, these navigation links are translated definitions of the current language. Since these definitions are saved in the database, they are not translated into the admin/client's language. e.g. An admin can install the Support Manager plugin (default lang = en_us). If a client uses a different default language, they will always see the en_us version of the translation for the Support Manager navigation links. We may want to consider saving the navigation definition term rather than it's definition translation, and allow for the navigation to load up the plugin's language file(s) to translate the definition on the fly to better support multi-language navigation links. |
Tyson Phillips (Inactive)
made changes -
| Description |
# Update `plugin_actions` to support translating the `name` field using language from the plugin. The plugin can then set an action that will represent the language definition to use (e.g. "SupportManagerPlugin.nav_primary_client.main")
# Whenever plugin actions are retrieved, load up and instantiate the associated plugin #* Call $this->_(..plugin definition..) on the plugin action definition to translate it * The navigation cache may need to be reset whenever someone changes their language or a plugin is installed/upgraded (which may or may not already take place) ---- When a plugin (e.g. Support Manger) is installed, it can register navigation links. Currently, these navigation links are translated definitions of the current language. Since these definitions are saved in the database, they are not translated into the admin/client's language. e.g. An admin can install the Support Manager plugin (default lang = en_us). If a client uses a different default language, they will always see the en_us version of the translation for the Support Manager navigation links. We may want to consider saving the navigation definition term rather than it's definition translation, and allow for the navigation to load up the plugin's language file(s) to translate the definition on the fly to better support multi-language navigation links. |
# Update `plugin_actions` to support translating the `name` field using language from the plugin. The plugin can then set an action that will represent the language definition to use (e.g. "SupportManagerPlugin.nav_primary_client.main")
# Whenever plugin actions are retrieved, load up and instantiate the associated plugin #* Call $this->_(..plugin definition..) on the plugin action definition to translate it * The navigation cache may need to be reset whenever someone changes their language or a plugin is installed/upgraded (which may or may not already take place) *Note: The language for the actions are assumed to come from /plugins/plugin_name/language/en_us/plugin_name_plugin.php*. If not set here then it will use the name of the plugin as given ---- When a plugin (e.g. Support Manger) is installed, it can register navigation links. Currently, these navigation links are translated definitions of the current language. Since these definitions are saved in the database, they are not translated into the admin/client's language. e.g. An admin can install the Support Manager plugin (default lang = en_us). If a client uses a different default language, they will always see the en_us version of the translation for the Support Manager navigation links. We may want to consider saving the navigation definition term rather than it's definition translation, and allow for the navigation to load up the plugin's language file(s) to translate the definition on the fly to better support multi-language navigation links. |
Tyson Phillips (Inactive)
made changes -
| Sprint | 4.5.0 Sprint 1 [ 66 ] | 4.5.0 Sprint 1, 4.5.0 Sprint 2 [ 66, 67 ] |
Tyson Phillips (Inactive)
made changes -
| Rank | Ranked higher |
Automated transition triggered when Tyson Phillips (Inactive) merged pull request #555 in Stash -
| Status | In Review [ 5 ] | Closed [ 6 ] |
