Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add positional preference for units #1329

Merged
merged 1 commit into from Dec 30, 2015
Merged

Add positional preference for units #1329

merged 1 commit into from Dec 30, 2015

Conversation

mwjames
Copy link
Contributor

@mwjames mwjames commented Dec 23, 2015

The unit position declared in [[Corresponds to::€ 1]] vs [[Corresponds to::1.06 USD, US$, $]]
determines the positional preference (prefix, suffix).

SemanticMediaWiki/SemanticResultFormats#135 (comment)

http://sandbox.semantic-mediawiki.org/wiki/Issue/1329_%28Positional_unit_preference%29

@mwjames mwjames added the enhancement Alters an existing functionality or behaviour label Dec 23, 2015
@mwjames mwjames added this to the SMW 2.4 milestone Dec 23, 2015
@mwjames
Copy link
Contributor Author

mwjames commented Dec 23, 2015

@jongfeli Would you be so kind and test this (it is based on your comments in SemanticMediaWiki/SemanticResultFormats#135 (comment))

@SemanticMediaWiki/testers are invited as well

@@ -66,7 +73,7 @@ class SMWNumberValue extends SMWDataValue {
* @return integer 0 (no errors), 1 (no number found at all), 2 (number
* too large for this platform)
*/
static protected function parseNumberValue( $value, &$number, &$unit ) {
static protected function parseNumberValue( $value, &$number, &$unit, &$asPrefix = false ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#naaaaw

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the whole thing needs a general overhaul but I'm not in a mood to bite the bullet yet (for once I want to add some new things not re-factor legacy stuff).

@jongfeli
Copy link
Contributor

My apologies for the delay @mwjames. I tested this with [0] and it works BUT @JeroenDeDauw's #naaaaw and your reaction to that probably means that the solutions is not what you want :)

Al-tough it is great to be able to define the unit position for a value, the way it is now and for units in front of the value this only makes sense when used inline or with {{#show:.... When the results are in a table then the position of the unit should depend on how big the biggest number in the result is, otherwise the unit or the number is all over the place (depending on alignment). This basically means that the [[Has type::Quantity]] datatype should give the user more control on how the numbers are presented.

You asked me to write a RFC, I will do this (after the holidays).

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/tree/pos-unit

@JeroenDeDauw
Copy link
Member

@jongfeli my previous comment is a code quality nitpick. It is not about the soundness of the overall approach.

@mwjames
Copy link
Contributor Author

mwjames commented Dec 28, 2015

. I tested this with [0] and it works

Thanks

#naaaaw and your reaction to that probably means that the solutions is not what you want :)

The overall quality of the DV classes are hard to extend hence my comment.

When the results are in a table then the position of the unit should depend on how big the biggest number in the result is, otherwise the unit or the number is all over the place (depending on alignment).

"Prefexial dependency" and output alignment are distinct issues that should not be mixed with each other. The alignment of numbers within a column table to display an ordered (in terms of space) position has to be done in a result printer which generates the HTML/wikitext.

This PR is about "positional preference" which is part of the DV (DataValue) itself to determine the relative correctness (correct in terms of what a user has defined to be either right or left) and keeps the information of the definition close that what the user has specified.

A single DV has no (and can not have) knowledge about a possible competing DV that may (or may not) appear in a printout and therefore cannot be made dependent on such at the time the DV is created.

Of course, you could have language dependant positional preference [0] but that cannot be solved with the current way general purpose quantity properties are defined.You would need to extend the Quantity DV and account for language specific output with the help of the i18n system.

[0] http://english.stackexchange.com/questions/11326/what-is-the-difference-between-20-and-20

The unit position declared in `[[Corresponds to::€ 1]]` / `[[Corresponds to::1.06 US, US$, $]]`
determines the positional preference (prefix, suffix).
@mwjames
Copy link
Contributor Author

mwjames commented Dec 30, 2015

... and for the due diligence fraction, I added some extra tests to cover things like [[Currency::<¥300]] OR [[Currency::≥1400 JPY]] OR [[Currency::< € .8]]

mwjames added a commit that referenced this pull request Dec 30, 2015
Add positional preference for units
@mwjames mwjames merged commit 7e7dfa1 into master Dec 30, 2015
@mwjames mwjames deleted the pos-unit branch December 30, 2015 08:34
@mwjames
Copy link
Contributor Author

mwjames commented Dec 30, 2015

@kghbln FYI

@kghbln kghbln added wikidocu missing Code changes (mostly features) what have not yet been documented and removed wikidocu missing Code changes (mostly features) what have not yet been documented labels Aug 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Alters an existing functionality or behaviour
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants