vincentsels
Added monthly translations
The month in 'time_registration_page' was directly the PHP string. With this little change should be translated according to the language file
Awesome! Gonna have a go at merging this. I'm going to make a few modifications, so won't auto-merge this.
Ok, so I tried merging this (incorporating the changes I made in the comments) locally. There's one thing that bothers me though: the fact that you need to duplicate the work_types (and unavailability_types) in the translations files, while you can easily modify them or add new ones in the config screen of the plugin. That's very contra-intuitive.
You could add a note on the config page warning the user that he has to reflect his changes in the string files, because otherwise it'd go wrong:
- If he renames the values through the config page, the values from the string files would still be used
- if he adds new values to the config page, he'd start seeing errors because there's no matching translation.
But then what's the point of still making this configurable, if you still have to go change those string files manually. In fact, the config values are completely useless, you could as well use the English translation string instead!
And I can't really come up with a solution for this... Of course, you could argue that it's the same with changing / adding enums in the Mantis core too: you also have to modify both the constants and the translations. So I'm probably nit-picking... what's your opinion ?
Hi Vincent,
It's correct it's contra-intuitive, but I have done following the same philosophy than with other core enums (severity, priority, ...). I had to add this strings (severity, priority, ...) to the languages files I support to get them translated.... of course, it's the argue you hoped.
So, by default, you could not add the enum strings in the languages files, leaving a comment on config page about how to get enums translated if needed. The code is taking by default the string defined on the enum, but if a translation is found, then it uses the translated string.
I think for most people no translation is needed, so only some people will need to add their translations manually. The fact is, you allow to get translations if someone needs and at the time don't annoy people who don't need.
I know it's not the better answer, but do you think it could be a solution?
Regards, Daniel Tamajón
2013/7/17 Vincent Sels [email protected]
Ok, so I tried merging this (incorporating the changes I made in the comments) locally. There's one thing that bothers me though: the fact that you need to duplicate the work_types (and unavailability_types) in the translations files, while you can easily modify them or add new ones in the config screen of the plugin. That's very contra-intuitive.
You could add a note on the config page warning the user that he has to reflect his changes in the string files, because otherwise it'd go wrong:
- If he renames the values through the config page, the values from the string files would still be used
- if he adds new values to the config page, he'd start seeing errors because there's no matching translation.
But then what's the point of still making this configurable, if you still have to go change those string files manually. In fact, the config values are completely useless, you could as well use the English translation string instead!
And I can't really come up with a solution for this... Of course, you could argue that it's the same with changing / adding enums in the Mantis core too: you also have to modify both the constants and the translations. So I'm probably nit-picking... what's your opinion ?
— Reply to this email directly or view it on GitHubhttps://github.com/vincentsels/ProjectManagement/pull/30#issuecomment-21078206 .
Agreed, using the default values from the config when no translations are found would be the ideal solution. If you can get that to work without too much of a performance loss, that'd be ideal! In that case, you can indeed leave out the default translations in the strings files. It's probably too complicated to include an explanation of how to change the translations in the config page. It's probably best to include that kind of explanation in a separate 'configuration' section in the README.md - but you can leave that to me :)
Regards,
Vincent
Vincent,
The current code is accepting not using enums in language files. I mean, if you delete the enums translation, it will work properly. If no translation is found, it will use the literals defined through config.
Once an administrator add translations, any change through the config page requires a review on the translation files. I think it's the easier way.
Regards, Daniel Tamajón
2013/7/17 Vincent Sels [email protected]
Agreed, using the default values from the config when no translations are found would be the ideal solution. If you can get that to work without too much of a performance loss, that'd be ideal! In that case, you can indeed leave out the default translations in the strings files. It's probably too complicated to include an explanation of how to change the translations in the config page. It's probably best to include that kind of explanation in a separate 'configuration' section in the README.md - but you can leave that to me :)
Regards,
Vincent
— Reply to this email directly or view it on GitHubhttps://github.com/vincentsels/ProjectManagement/pull/30#issuecomment-21103397 .
Hi Vincent,
Could you have a look to the code?
Regards, Daniel Tamajón
2013/7/18 Daniel Tamajon [email protected]
Vincent,
The current code is accepting not using enums in language files. I mean, if you delete the enums translation, it will work properly. If no translation is found, it will use the literals defined through config.
Once an administrator add translations, any change through the config page requires a review on the translation files. I think it's the easier way.
Regards, Daniel Tamajón
2013/7/17 Vincent Sels [email protected]
Agreed, using the default values from the config when no translations are found would be the ideal solution. If you can get that to work without too much of a performance loss, that'd be ideal! In that case, you can indeed leave out the default translations in the strings files. It's probably too complicated to include an explanation of how to change the translations in the config page. It's probably best to include that kind of explanation in a separate 'configuration' section in the README.md - but you can leave that to me :)
Regards,
Vincent
— Reply to this email directly or view it on GitHubhttps://github.com/vincentsels/ProjectManagement/pull/30#issuecomment-21103397 .