https://bugzilla.wikimedia.org/show_bug.cgi?id=32661
Markus Krötzsch <mar...@semantic-mediawiki.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Comment #7 from Markus Krötzsch <mar...@semantic-mediawiki.org> 2012-02-11
23:37:21 UTC ---
This sounds to me like an upgrade issue. In current SMW, the database should
always use "." in the database, whatever the surface language. The value is
generated using PHP's strval() and recovered with floatval(); no localisation
is involved. This is intentional and ensures that values are exchanged between
PHP and SQL as simple and fast as possible, while more complex
language-specific handling may come later (and only if needed). This also means
that, unless PHP would for some reason localise the output of strval(), the
smw_atts2 table should never contain a value in pretty printing (neither
localised nor with thousands separators). Therefore, the "fix" suggested in
Comment 4 is not required or desired in SMW, and the current behaviour is not a
bug.
My suggestion is to refresh all stored data using Special:SMWAdmin to make sure
that outdated values are fixed. Besides stale data from earlier SMW versions,
another possible reason for "number-like" values with localised decimal
separators to appear in the database is that the datatype of the respective
properties has been changed at some point (e.g., to String). The value will
then be stored verbatim, but using the same table (however, without using the
numerical value_num cell as reported above). When changing the type back to
Number, such stored values cannot be interpreted properly. This is normal and
to be expected (it is more obvious for other types, such as Date). SMW
automatically triggers update jobs that should fix all affected database
records after a while, but how fast this is depends on the wiki's job queue.
SMW can only have one localisation setting for wiki text (just like MediaWiki),
i.e., all pages should be in the same language. I am sorry that something got
mixed up on your wiki, but as long as this cannot be reproduced anywhere else
and analysis of code does not suggest any problem, I can only close this as
worksforme.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
