Added monthly translations

[dtamajon]

The month in 'time_registration_page' was directly the PHP string. With this little change should be translated according to the language file

[vincentsels]

Awesome! Gonna have a go at merging this. I'm going to make a few modifications, so won't auto-merge this.

[vincentsels]

I think that's indeed the correct place. I'd add some comments though, something like:

/**
 * This is essentially the plugin version of get_enum_element in core/helper_api.
 * Given a plugin enum string and num, return the appropriate string for the
 * specified user/project
 * @param string $p_enum_name
 * @param int $p_val
 * @param int|null $p_user user id, defaults to null (all users)
 * @param int|null $p_project project id, defaults to null (all projects)
 * @return string
 */

[vincentsels]

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 ?

[dtamajon]

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 notifications@github.com

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//pull/30#issuecomment-21078206
.

[vincentsels]

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

[vincentsels]

Is this function used anywhere ? Can't find any references - at least not in this master branch, perhaps you use it in other branches of yours ?

[dtamajon]

Vincens,

I'm using it in a peace of code that is not still pushed

Regards,
Daniel Tamajón

2013/7/17 Vincent Sels notifications@github.com

In ProjectManagement/pages/html_api.php:

}

}

+function print_plugin_enum_string_selected_value( $p_enum_name, $p_val = 0 ) {

Is this function used anywhere ? Can't find any references - at least not
in this master branch, perhaps you use it in other branches of yours ?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/30/files#r5238366
.

[dtamajon]

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 notifications@github.com

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//pull/30#issuecomment-21103397
.

[dtamajon]

Hi Vincent,

Could you have a look to the code?

Regards,
Daniel Tamajón

2013/7/18 Daniel Tamajon dtamajon@litesolutions.es

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 notifications@github.com

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//pull/30#issuecomment-21103397
.