i18n english locale

[bouks]

Should we include default english in grid.base.js as it was done in lasts commits ?

If so, shouldn't we remove the english locale in i18n ?

Duplicates are not cool.

In the actual state, some users would include english locale and therefore add unnecessary request to server.

[meh-uk]

I didn't include the default English in the codebase as I thought there was a consensus against it.

[flack]

Hm, maybe I merged it with some of @OlegKi's without noticing it, but it's there in current HEAD:

https://github.com/openpsa/grid.js/blob/master/js/grid.base.js#L20

[bouks]

@flack Yes it's there, so that's why my question. :)

[meh-uk]

IMO I think we should remove it.

[flack]

The file or the inlined version?

[smartcorestudio]

That's the reason for that I think, it was in this Oleg's commit: https://github.com/openpsa/grid.js/commit/c02ac04c14c1e17747dd635a285d344495f6b368

[bouks]

Two possibilities :

• remove english file and specify in the documentation that english is built-in but user can change language by including proprer file.
• remove english in base and let english file.

The first avoid english spoken people to include one more file.

[meh-uk]

The second makes it easy for people who aren't supporting English.

[bouks]

Not much easy for them, this will be the same as now. No ?

[flack]

I can see why it might be nice for new users to have one less thing to worry about, but it makes the jqgrid file bigger than it has to be for everyone not using English.

Just as a sidenote: Removing the en file would cause 404s with my server code:

$lang = "en";
$language = midcom::get()->i18n->get_current_language();
if (file_exists(MIDCOM_STATIC_ROOT . $jqgrid_path . 'js/i18n/grid.locale-' . $language . '.js'))
{
    $lang = $language;
}
$head->add_jsfile(MIDCOM_STATIC_URL . $jqgrid_path . 'js/i18n/grid.locale-'. $lang . '.js');

It basically tries to load the file for the current language, and if it's not available, it falls back to en. I'm not sure how many people have a similar loading mechanism, but I thought I'd mention it.

[bouks]

@flack

For what you raise :

• or you change your PHP code
• or we keep english file and remove it in base.

Note that the file get a little bigger, but, in case of english, it avoids an include and then one more server call. :)

Like we say in french : "on ne peut pas avoir le beurre et l'argent du beurre" that in google translation make (i hope it's good translation): "have your cake and butter money"

:)

[flack]

I think the English equivalent would be "You can't have your cake and eat it, too". Google Translate est nul des fois :-)

About the PHP code: Sure, it is a trivial fix. I just wanted to let you know that there might be some side effects on the server side. But we can add that to the release notes if we remove the file

[meh-uk]

We are also asking for yet another serverside change for existing users if we include it. And they should be avoided.

[meh-uk]

Plus I'd have thought special casing English to not include the locale was worse than including it.

On the other hand now we've corrected the language codes that code will need changing anyway so .

[bouks]

I think we just have to vote.

I vote for nothing : ) . My only concern is not to have duplicates and confusion.

[flack]

the funny thing is that at least in my case, removing the en locale file makes my server code shorter:

$language = midcom::get()->i18n->get_current_language();
if (file_exists(MIDCOM_STATIC_ROOT . $jqgrid_path . 'js/i18n/grid.locale-' . $language . '.js'))
{
    $head->add_jsfile(MIDCOM_STATIC_URL . $jqgrid_path . 'js/i18n/grid.locale-'. $language . '.js');
}

For reasons of symmetry, it would be nice to keep the en file. But if it only includes redundant information, then we should remove it. In short: I am undecided, too :-) Maybe we should flip a coin at the call later today. That is still planned, isn't it?

[flack]

P.S.: Another option would be to solve this in the build system: We could keep the en strings in the separate file, and then just add it as the first file when the JS is concatenated. This would also mean that in the download builder, we could offer the option to select the default grid locale, i.e. if someone wants French, they would get the fr file included in grid.min.js, thus having the benefit of one less request, while still avoiding the unneeded weight of an unused locale file

[bouks]

@flack yes would be cool. In charge of the backend dev to include dynamically other file like you did.

[flack]

The only problem I see is that the bundled locale would probably override the other locale file, e.g. if you have something like this:

<script src="grid-locale-ru.js"></script>
<script src="grid-with-bundled-en-locale.min.js"></script>

Then the bundled en would probably overload the ru file. So we would need to add some kind of detection for that situation (but that shouldn't be too hard to do)

[flack]

This is implemented now as discussed. The behaviour is as follows:

• grunt inserts en by default in build and dist file (can be configured to a different locale)
• Download builder does not include a lang by default, but you can select any one of them
• if you do a custom build without default locale and you then forget to include the locale yourself, you get an alert on startup as in 4.7

Documentation still needs to be updated, but download builder is online

[flack]

P.S.: and if you have a custom locale in your build, and you include a separate locale file before grid.min.js, the built-in default gets overridden by the file

[meh-uk]

Sounds good :)