Pagetable field stripping off decimals when using german language?

[bernhard]

Hi everyone,

I have a quite old and stable website running 2.7.2 multilang (only for having a german admin, the frontend is german only). Today my client told me that they cannot save decimal values to the price fields in repeaters. I narrowed it down and the strange thing is that it works on the default language (english) but does not work when the users language is german. It just strips off everything after the comma.

First I thought that might have something to do with dot/comma sign, but it's the same for both. Also my module that replaces , by . is not the reason.

I created a new test-field of type float and this single field worked without an issue.

The pagetable item is of type "decimal". I tried "float" as well. Same result.

The quickfix is that i switched the admin for my client back to english - not ideal but it works. Does anybody have ideas what I could check? Any of you ever had a similar problem?

Thanks

[Soma]

It most likely the locale setting in the de language pack that affects numbers. There was once a fix I thought around that time.

[bernhard]

Interesting... When I delete all translation files it works... 

OK, found the file... As soon as I upload wire--modules--languagesupport--languagesupport-module.json it breaks. All other translation files seem to work. Any ideas what could cause this strange problem??

It's not important, because I have again a working german admin with decimals but maybe that's worth a bugreport? No idea thought what the bug is actually...

[Soma]

Well look into that translation to see the locale.

[bernhard]

Thanks for your help so far. I would not have asked if I knew where to look and what for. I've also only very limited experience with locales, so I don't know where and what for I could look. I just inspected the file that causes the problem and I didn't see anything strange..

[BitPoet]

There's a translated string for LanguageSupport.module named "C" that holds the locale string passed to PHP's setlocale() function.

[bernhard]

{
    "file": "wire\/modules\/LanguageSupport\/LanguageSupport.module",
    "textdomain": "wire--modules--languagesupport--languagesupport-module",
    "translations": {
        "4994a8ffeba4ac3140beb89e8d41f174": {
            "text": "Sprache"
        },
        "185d23ff9526ad93077a1c9ad5ed26a2": {
            "text": "E-Mail-Adresse"
        },
        "b78a3223503896721cca1303f776159b": {
            "text": "Titel"
        },
        "0d61f8370cad1d412f80b84d143e1257": {
            "text": "de_DE"
        },
        "3f94f86633491ad8e5d18f5e481330c2": {
            "text": "\u00c4nderungen zu diesem Feld werden nicht gespeichert weil Sie nicht berechtigt sind f\u00fcr folgende Sprache: %s."
        }
    }
}

Sorry @BitPoet I don't get what you are saying  The locale is de_DE (of course). But I have no clue how this whole locale thing works and where the problem is. Maybe it's on my server? locale -a shows:

C
C.UTF-8
de_DE
de_DE.iso88591
de_DE.utf8
deutsch
en_US
en_US.iso88591
en_US.utf8
german
POSIX

Thx everybody so far!

[BitPoet]

That de_DE could the culprit. You could try putting "LC_ALL=de_DE.utf8;LC_NUMERIC=C" (without the quotes) there instead (through the backend) to use German locale settings for everything but numeric things, for which the system's default locale will be used.

[bernhard]

Thx, i removed the locale setting from the translation file ( it's here if anybody is interested: /setup/language-translator/edit/?textdomain=wire--modules--languagesupport--languagesupport-module ) and it works. Don't know if your line really helps - I think it's just ignored since XXX also works (just like leaving the field empty).

As long as I don't have any other issues with the default locale I'll continue using it.

[BitPoet]

XXX will be treated as an invalid locale and PHP falls back to the system's default locale (which is also used when the translation is empty). My line wouldn't be ignored, but unless there are any other functions using the locale, e.g. if you use a date format with weekday or month strings somewhere, there won't be any visible differences.

[bernhard]

1 minute ago, BitPoet said:

XXX will be treated as an invalid locale and PHP falls back to the system's default locale (which is also used when the translation is empty). My line wouldn't be ignored, but unless there are any other functions using the locale, e.g. if you use a date format with weekday or month strings somewhere, there won't be any visible differences.

Yep, thx, I believe you  The thing is just that I was unclear here:

13 minutes ago, bernhard said:

Don't know if your line really helps - I think it's just ignored since XXX also works

de_DE does not work

LC_ALL=de_DE.utf8;LC_NUMERIC=C does work, but:

LC_ALL=de_DE does also work, so I guess your example is ignored because it is wrong somehow.

Quote

Value to pass to PHP's setlocale(LC_ALL, 'value') function when initializing this language 
Default is 'C'. Specify '0' to skip the setlocale() call (and carry on system default).

This is the description of the field, so I think your example would lead to something like

setlocale(LC_ALL, 'LC_ALL=de_DE.utf8;LC_NUMERIC=C')

...and I guess that is wrong and therefore ignored

[Soma]

I can't reproduce and it works flawless in pw2.7.2 float. Whether , or . PW handles it.

Locale is important only for Date strings and Number formats. So unless you use strftime() to print "Montag, 1. April 2018" it can be ignored.

[BitPoet]

I peeked into the setLocale method in Languages.php ($locale is fetched from the translation in wire--modules--languagesupport--languagesupport-module).

			} else if(strpos($locale, ';') !== false) {
				// multi-category and locale string, i.e. LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=C
				foreach(explode(';', $locale) as $s) {
					// call setLocale() for each locale item present in the string
					if(strpos($s, '=') === false) continue;
					list($cats, $loc) = explode('=', $s); 
					$cat = constant($cats);
					if($cat !== null) {
						$loc = $this->setLocale($cat, $loc);
						if($loc !== false) $setLocale .= trim($cats) . '=' . trim($loc) . ";";
					}
				}
				$setLocale = rtrim($setLocale, ';');
				if(empty($setLocale)) $setLocale = false;
			}

LC_ALL=de_DE is a different case, as it contains no semicolon and is therefore passed verbatim as the value to setlocale.

[bernhard]

4 minutes ago, Soma said:

I can't reproduce and it works flawless in pw2.7.2 float. Whether , or . PW handles it.

Inside a pagetable?

Quote

I created a new test-field of type float and this single field worked without an issue.

 

[Soma]

11 minutes ago, bernhard said:

Inside a pagetable?

 

What's the difference? Pagetable are pages that are edited in the modal. 

Your screenshot in OP doesn't show a pagetable btw.

[bernhard]

2 minutes ago, Soma said:

Your screenshot in OP doesn't show a pagetable btw.

Sorry and thx, it's a ProfieldsTable  Anyhow... I don't want to dig deeper into this issue. Thanks for all your help. I could file a bugreport, but I would have to check a lot more if it is a bug or just a misconfiguration on my side. No time for that atm, and you helped me to identify what is the issue and so I can happily live with that, thx

[BitPoet]

21 minutes ago, BitPoet said:

I peeked into the setLocale method in Languages.php

and peeked again in the github repo to find that the setLocale part was added in 2017, so 2.7.2 won't have that (yet). So, yes, my line is likely a no-op.