Skip to content
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

CFV Localisation #1167

Closed
wants to merge 13 commits into from
Closed

CFV Localisation #1167

wants to merge 13 commits into from

Conversation

totalwarANGEL
Copy link

Becase there isn't any way to localize the CF, we implemented out own way of storing CFV. For the table mantis_custom_field_table, we have created a language map mantis_custom_field_localized_table were localized CFV are stored indexed by the id and the language. The original tables still remains but are only accessed if there is no match in the language map. We have also done some changes in the interface to support entering values for differend languages.

@atrol
Copy link
Member

atrol commented Sep 3, 2017

I didn't have a deeper look, but build fails and there are quite a lot of changes (e.g. white space and comment style) which make it hard to review.

Maybe @cproensa is interested in having a first look at it, as he opened 0020305: Create localization framework for user created objects.

@cproensa
Copy link
Contributor

cproensa commented Sep 3, 2017

Maybe @cproensa is interested in having a first look at it, as he opened 0020305: Create localization framework for user created objects.

The idea for a possible implementation is somewhat similar to what's proposed here. However, i'd prefer a more general approach: instead of having one "localised" table for each item, have one single table for translations. So if implemented, the solution should cover all user generated elements: custom fields, project names, category names, etc. And also support translation for arbitrary plugin elements.
On the UI side: my bet is to have some kind of javascript component that can hook on needed inputs, thus avoiding having to write specific pages/html for each element management of translations.
On core: a deep rewrite of how the name of these elements are fetched. With an intermediate layer for this, the implementation details should be transparent.

I didn't have a deeper look, but build fails and there are quite a lot of changes (e.g. white space and comment style) which make it hard to review.

Build fails because the tables are not registered in the schema updates.
Anyway, the details are difficult to read because of the non-related changes (whitespace, etc)
I feel that this PR don't fully cover the needed solution, which due to its complexity, should also go through some kind of rfc process first

@totalwarANGEL
Copy link
Author

I am really sorry for the many changes of whitspaces and so on. I screwed up with my IDE and realized it to late. The plan was to keep the structure as it is as far as possible. The objective was to find a solution to adjust mantis to our needs and keep it updatable. And yes, the "we" has shrunk to a "me".
So there is something similar to this suggestion going on. I will look into it.

@dregad
Copy link
Member

dregad commented Oct 25, 2017

@totalwarANGEL I'll close this for now. Feel free to reopen or submit another PR at a later time, and make sure it is linked to an issue in our bugtracker.

@dregad dregad closed this Oct 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants