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

Edit form Physical Object section inputs should default to either metric or imperial/American, but not both. #2242

Closed
seabelis opened this issue Jul 30, 2019 · 11 comments · Fixed by #4134
Labels
Affects: Librarians Issues related to features that librarians particularly need. [managed] Good First Issue Easy issue. Good for newcomers. [managed] hacktoberfest Issues appropriate for Hacktoberfest participants Lead: @cdrini Issues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed] Needs: Response Issues which require feedback from lead Priority: 3 Issues that we can consider at our leisure. [managed] Theme: Affiliate API Theme: Editing Issues related to the user editing/wiki editing experience. [managed] Type: Bug Something isn't working. [managed]
Milestone

Comments

@seabelis
Copy link
Collaborator

Description

The weight defaults to grams; dimensions to inches.

Evidence / Screenshot (if possible)

Fullscreen capture 7302019 32557 PM bmp

Relevant url?

Expectation

The default should be one system or the other. Ideally, the data would be appended, not overwritten if someone adds value of another type.

Details

  • Logged in (Y/N)?
  • Browser type/version?
  • Operating system?

Proposal & Constraints

Stakeholders

@seabelis seabelis added Type: Bug Something isn't working. [managed] Affects: Librarians Issues related to features that librarians particularly need. [managed] labels Jul 30, 2019
@cdrini cdrini added the Good First Issue Easy issue. Good for newcomers. [managed] label Jul 30, 2019
@cdrini
Copy link
Collaborator

cdrini commented Jul 30, 2019

It should default to imperial (for now). Eventually, once we get proper localization we can make the default locale specific, but for now it should default to imperial.

@seabelis seabelis changed the title Edit form Physical Object section inputs should default to either metric or imperial, but not both. Edit form Physical Object section inputs should default to either metric or imperial/American, but not both. Jul 30, 2019
@tabshaikh tabshaikh added the hacktoberfest Issues appropriate for Hacktoberfest participants label Sep 27, 2019
@tabshaikh tabshaikh added this to the Hacktoberfest milestone Sep 27, 2019
@LeadSongDog
Copy link

LeadSongDog commented Oct 16, 2019

@cdrini Was there some rationale for choosing Imperial as the default? Even in the US, repository libraries principally use SI units for new records, while still supporting older records using Imperial. Other things being equal, it would seem to make sense to prefer units understood by the whole world, rather than just a fractional area.

AMZ sites use the units customary to current business in a specific country, so amazon.de uses cm with the decimal comma (https://www.amazon.de/Tall-Tales-Wee-Stories-Connolly/dp/1529361338/) while amazon.co.uk and amazon.co.jp use cm with the decimal point (https://www.amazon.co.uk/Tall-Tales-Wee-Stories-Connolly/dp/1529361338/) and amazon.com uses both inches and pounds with the decimal point (https://www.amazon.com/Tall-Tales-Wee-Stories-Connolly/dp/1529361338/) Most of the AMZ sites (except the US one) omit the weight entirely, and where it is shown, it is sometimes for a boxed product shipping weight.

For automated import, it would be simple enough to just accept the stated value and units in a source record:
MARC records explicitly state the units with the numeric values (in field 300 subfield $c as seen at http://www.loc.gov/marc/bibliographic/bd300.html);
MODS 3.5 and later added the attribute "unit" to the "extent" subordinate element of the "physicalDescription" element (as seen at http://www.loc.gov/standards/mods/v3/mods-3-5.xsd );
However, when more than one source bibliographic record describes a specific edition, the possibility arises that different cataloguers used different units for the same edition. We don't want to have duplicate edition records, so one must predominate. This should reasonably be the more future-proof choice.

@seabelis
Copy link
Collaborator Author

I'd favour metric, but would mostly favour consistency.

@cdrini
Copy link
Collaborator

cdrini commented Oct 29, 2019

Until we have proper i18n, we have to take into account that the majority of our users are in the US. That sucks, I know (I'm Canadian, we use metric (like normal people)).

I actually don't think it will be super difficult to make this i18n-aware; we should try to make that work if possible; but if that's not easily achievable, I think we'd have to use imperial just to match expectations of the majority of our users :/

@cdrini cdrini self-assigned this Oct 29, 2019
@cdrini cdrini added the Priority: 3 Issues that we can consider at our leisure. [managed] label Oct 29, 2019
@tfmorris
Copy link
Contributor

I favor metric as well.

The current storage format is a concatenated string of all the dimensions, which is kind of silly, but we can fix that separately. I've created #2587 for that piece.

@xayhewalo xayhewalo added Theme: Editing Issues related to the user editing/wiki editing experience. [managed] State: Backlogged labels Nov 24, 2019
@mekarpeles mekarpeles added the Lead: @cdrini Issues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed] label Dec 18, 2019
@manav014
Copy link

I can handle the issue and set the default to metric. May I please get some code pointers.

@kazikhanmargulan
Copy link

Hello, guys! Was the issue closed? If not, may I try to resolve this?

@mekarpeles
Copy link
Member

mekarpeles commented Apr 4, 2022

@kazikhanmargulan if you feel like you have enough information to give it a try, feel free!

EDIT: actually, it looks like we may have a PR open for this #4134 which @cdrini may wish to provide feedback on before we get started (sorry for putting the cart before the horse)

@mekarpeles mekarpeles assigned kazikhanmargulan and unassigned cdrini Apr 4, 2022
kazikhanmargulan added a commit to kazikhanmargulan/openlibrary that referenced this issue Apr 14, 2022
Changed default inputs as kilos for weight and centimeters for dimensions.
@kazikhanmargulan
Copy link

I kind of did the exact same thing as was done on the mentioned issue commit. If you would want me to pull request it, let me know.

@mekarpeles mekarpeles added the Needs: Response Issues which require feedback from lead label Apr 18, 2022
@mekarpeles mekarpeles added Needs: Triage This issue needs triage. The team needs to decide who should own it, what to do, by when. [managed] and removed Priority: 3 Issues that we can consider at our leisure. [managed] labels May 9, 2022
@cdrini cdrini added Priority: 3 Issues that we can consider at our leisure. [managed] and removed Needs: Triage This issue needs triage. The team needs to decide who should own it, what to do, by when. [managed] labels May 1, 2023
Copy link

Assignees removed automatically after 14 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Affects: Librarians Issues related to features that librarians particularly need. [managed] Good First Issue Easy issue. Good for newcomers. [managed] hacktoberfest Issues appropriate for Hacktoberfest participants Lead: @cdrini Issues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed] Needs: Response Issues which require feedback from lead Priority: 3 Issues that we can consider at our leisure. [managed] Theme: Affiliate API Theme: Editing Issues related to the user editing/wiki editing experience. [managed] Type: Bug Something isn't working. [managed]
Projects
None yet
Development

Successfully merging a pull request may close this issue.