View Issue Details

IDProjectCategoryView StatusLast Update
0020305mantisbtlocalizationpublic2022-08-02 09:47
Reportercproensa Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status newResolutionopen 
Summary0020305: Create localization framework for user created objects
Description

Mantis already supports localization of static strings used through the application.
However, with the current system, there is no possibility to localize runtime objects created by the user
A facility should be provided so the user can maintain customized translation for different objects such as project names, categories, custom field values, etc

This is a good feature for scenarios where a unique application is used by several groups of users with different languages. For example: an organization which spans several countries, with some teams of users localized for each area.

TagsNo tags attached.

Relationships

related to 0008234 new Localized categories 
related to 0005636 new Store custom fields ids, not their values. 
related to 0020512 new Renaming custom fields breaks column configuration 
related to 0030818 closedatrol Is it Possible to translate the values of a custom field ? 

Activities

mukeshchaubey

mukeshchaubey

2015-11-23 22:28

reporter   ~0051926

Please guide me how to enable this feature. I want to assign some task base on location or city name .

atrol

atrol

2015-11-24 02:42

developer   ~0051927

mukeshchaubey,
this is a feature request, not an existing feature.
It can't be enabled, it has to be implemented.

vboctor

vboctor

2016-01-26 01:44

manager   ~0052389

This would be a nice feature to support. However, it would be good to hear the proposal. We should take the following into consideration:

  • How does localization affect performance?
  • Is the goal to provide localization only for such objects? Or can someone use it to override standard terms (e.g. Issue -> Case). My feel is that just objects would do.
  • Will our API story hold together? What happens when I submit issues with localized project name and categories. We probably can evaluate what we do with statuses for example. Though often I think the API should return the "internal name" as well as the localized name, rather than just one of them.
  • What is the UX for users to provide such localization?
cproensa

cproensa

2016-01-29 13:43

developer   ~0052440

How does localization affect performance?
probably one or two additional query for fetching the translation. Not accounting for possible cache strategies...

Is the goal to provide localization only for such objects?
It would depend on the implementation. But i'm thinking this should be tied to object specific localization. Not a sort of generic dictionary.

Will our API story hold together? What happens when I submit issues with localized project name and categories.
Current bug history stores ids for some values, like project ids, or enumeration keys.
However custom fields, and categories are some that are stored by literal value. As the example of custom fields, that is already an issue.
In those cases, if there is a technical name (when not being possible tu use a nuemeral id), that technical name should be stored in history, and presented on localized form to the user.

it would be good to hear the proposal.
good question...

one proposal could be a central repository, defined by:
[context, object, id, value, lang, text]

So for example, for a project id:
[ 'core', 'project', 1, null, 'ES', 'nombre del proyecto' ]
Note that a deeper level could be achieved to translate enumerated custom field values
[ 'core', 'custom_field', 'field_name', 'value 1', 'ES', 'valor 1' ]
And support plugins:
[ 'plugin_xxx', 'task', 1, null, 'ES', 'Pruebas de usuario' ]

What is the UX for users to provide such localization?

In the previous example of an implementation, a possible user interface may be a hookable ajax control. Any managed field classified with proper keys could trigger a dialog to manage the localization subsytem.
So no need to do much specific work with static manage pages.
However this is a great leap into the discussion on switching UI, rely on JS, etc.

So that was just brainstorming...

totalwarANGEL

totalwarANGEL

2017-09-29 07:15

reporter   ~0057850

@cproensa
As you had mentioned, our ideas are somewhat similar.
(-> https://github.com/mantisbt/mantisbt/pull/1167)
Maybe we can put our heads together.