Template talk:Size

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Examples[edit]

1. {{Size|cm|40.6|50.8}} generates:   40.6 × 50.8 cm (15.9 × 20 in)
2. {{Size|cm|18|20.2|prec=1}} and {{Size|cm|25|20.4|prec=1}} generate:

18 × 20.2 cm (7 × 7.9 in)
25 × 20.4 cm (9.8 × 8 in)

3. {{Size|ft|3|5.2|prec=2}} generates:

Bahasa Indonesia: 4

3 × 5.20 ft (91.44 × 158.49 cm)
4. {{Size|cm|27}} generates:

Bahasa Indonesia: 13

27 cm (10.6 in)
5. {{Size|ft|1800|2050}} generates:   1,800 × 2,050 ft (548.6 × 624.8 m)
6. {{Size|cm|34.567|922.123|prec=1}} generates:

Bahasa Indonesia: 5

34.5 × 922.1 cm (1.1 × 30.2 ft)

7. {{Size|km|12.1234|98.1234|prec=2}} generates:   12.12 × 98.12 km (7.53 × 60.97 mi)
I added 5 concise examples, at top. -Wikid77 (talk) 10:04, 22 September 2009 (UTC)[reply]

inch in option ?[edit]

Hello, Would it be possible not to print the value in inches, if it is not required ? For instance, I would like to never see this in French.. Frédéric (talk) 17:06, 2 August 2009 (UTC)[reply]

As far as I know, the inch is only used in English-speaking countries. So it should be okay to remove the inch entirely except if the language defined in the preferences is set to English. --Slomox (talk) 18:12, 2 August 2009 (UTC)[reply]
It's kinda funny that you can define painting dimensions in miles. :) Rocket000 (talk) 15:51, 3 August 2009 (UTC)[reply]
The template is mainly used for paintings, but it is not limited to paintings. You could for example provide the size of a satellite image in miles (or, of course, in inches ;-) ) --Slomox (talk) 22:52, 3 August 2009 (UTC)[reply]
I changed the code of the template so it now allows localization on a per-language base. If you want to get rid of the inches in French, just copy the code of {{Size/nds}} to {{Size/fr}}. --Slomox (talk) 02:01, 13 December 2009 (UTC)[reply]

Changed to use magic-word formatnum[edit]

22-Sep-2009: After getting incorrect decimal digits displayed several times, I changed the template's internal coding (on 22-Sep-2009) to use magic-word "formatnum:" instead of using the customized Template:Formatnum to put commas in larger numbers. Numbers such as 20.4 were being displayed as "20.3" so the results were bizarre in terms of normal culture, where tenths of a unit do not change when displayed by typical computers. -Wikid77 (talk) 10:04, 22 September 2009 (UTC)[reply]

Adding 3rd dimension[edit]

I would like to propose adding a optional 3rd dimension to the template, per discussion here. I think the best way would be to rename {{{4}}} to {{{precision}}} and add use {{{4}}} as an optional 3rd dimension. This can be probably done by adding a temporary auto-category to all the pages using {{Size}} with specified precision and add "precision=" in front of the 4th argument in all those templates. Than we would be free to use {{{4}}}. Opinions? --Jarekt (talk) 13:14, 15 April 2010 (UTC)[reply]

Another option would be to create three new parameters "height", "width", "depth". "height" and "width" would be synonyms of "1" and "2". That way we can be sure nobody messes up the order of the three dimensions. --Slomox (talk) 13:50, 15 April 2010 (UTC)[reply]
I like it, but I would also add {{{precision}}} synonymous with {{{4}}}. --Jarekt (talk) 15:30, 15 April 2010 (UTC)[reply]
Sounds good.
I just realized, that the third dimension is not called "depth" in English (unlike in German with the cognate "Tiefe") but according to en:File:Height demonstration diagram.png it's length × height × width. Is that correct? I'm a bit unsure.
I prepared some code to go 3D, but I don't want to put it in the live template until I'm sure the names for the dimensions are meaningful. ;-)
To make it easier I added some tooltips in the code, like this (hover the mouse over the numbers): 1.5 × 2.5 × 3.5 cm. That way everybody will be able to determine which value is which dimension. --Slomox (talk) 21:02, 15 April 2010 (UTC)[reply]
If I come to think about it, the dimension names length × height × width could be quite intransparent to people who don't know English well. Height is clear, but if I hadn't looked it up some moments ago, I would be unsure what length and width refer to. Perhaps we should use something that is more straightforward or international. Perhaps something like "leftright", "bottomtop", "frontback" or - to use something symbolic instead of requiring English skills - "--", "I", "/" (I'm not sure whether it will be clear to most people that the slash is meant to indicate oblique projection ;-) , perhaps somebody can come up with something better, which will be understood more easily). --Slomox (talk) 21:13, 15 April 2010 (UTC)[reply]
I would use width * height * depth or x * y * z --Jarekt (talk) 00:05, 16 April 2010 (UTC)[reply]
Maybe we should just make it into a separate template, e.g. {{3dsize}}. This shouldn't be too complicated to implement and we could provide BrooklynMuseum with a response. -- User:Docu at 07:56, 20 April 2010 (UTC)[reply]
I am working on modifying the current one it should not be long. --Jarekt (talk) 12:46, 20 April 2010 (UTC)[reply]

✓ Done I just uploaded new version of the template supporting 1D, 2D and 3D measurements. --Jarekt (talk) 15:17, 20 April 2010 (UTC)[reply]

How are you going to make sure all instances of the template that use parameter "4" for precision are corrected? As soon as somebody starts to use parameter 4 for depth it will be hard to tell them apart. --Slomox (talk) 17:49, 20 April 2010 (UTC)[reply]
Couldn't it switch based on the units in 1? -- User:Docu at 18:02, 20 April 2010 (UTC)[reply]
We could use different defaults based on units, but I do not see much reason why. --Jarekt (talk) 18:25, 20 April 2010 (UTC)[reply]
I mean between 2 or 3 fields for sizes based on units, not for precision. -- User:Docu at 18:29, 20 April 2010 (UTC)[reply]
I am tagging all images currently using {{{4}}} with {{Empty}} template and monitor the list of files transcribing {{Empty}} templates. Strangely almost all the instances where {{{4}}} was used were cases when someone mistakenly used it for depth, otherwise I add "prec=" in front of the 4th parameter. I put in the tag several hours ago so we will need to wait for a day or two for all the files using it to show up. --Jarekt (talk) 18:24, 20 April 2010 (UTC)[reply]

Length × height?[edit]

I am confused with the order of height and length. The ISO standard uses length x height, but in arts it is commonly used height x length. I have taken some random samples: Musée d'Orsay, Art Institute of Chicago, The Hermitage. This is how this template is mostly used. --V.Riullop (talk) 07:39, 21 April 2010 (UTC)[reply]

Maybe it's just the documentation that needs updating as the template displays the values independently from how they are entered. -- User:Docu at 08:43, 21 April 2010 (UTC)[reply]
In the previous paragraph I suggested to give the parameters names. That way it should be clear to everybody which parameter means what. I also suggested to use tooltip hints so the reader can easily get the info which number is which dimension.
We cannot just update the documentation and change the order. We would loose any information which value is which dimension for all uploads so far. Okay, forget that. If the documentation says "WxH" and users so far mostly used "HxW" then we have already lost the information. One more reason for named parameters. Make the numbered parameters deprecated. Afterwards use a bot and update the numbered parameters to named parameters using the file dimensions as a hint which value is which dimension. --Slomox (talk) 10:48, 21 April 2010 (UTC)[reply]

✓ Done I introduced optional named parameters. See examples:

Code Output
{{Size|cm|10|20|30}} 10 × 20 × 30 cm (3.9 × 7.8 × 11.8 in)
{{Size|unit=cm|height=10|width=20}} height: 10 cm (3.9 in); width: 20 cm (7.8 in)
dimensions QS:P2048,10U174728
dimensions QS:P2049,20U174728
{{Size|unit=cm|width=10|height=20|depth=30}} height: 20 cm (7.8 in); width: 10 cm (3.9 in); depth: 30 cm (11.8 in)
dimensions QS:P2048,20U174728
dimensions QS:P2049,10U174728
dimensions QS:P5524,30U174728

--Jarekt (talk) 13:11, 21 April 2010 (UTC)[reply]

I would leave currently used templates as they are. We are not sure what order users used, and in a way it does not matter much if a painting is a landscape and {{{1}}}<{{{2}}} than we know that the sizes are reversed. No big deal but hard to fix by bot. --Jarekt (talk) 13:16, 21 April 2010 (UTC)[reply]
I don't think, we need x,y,z. We should keep it simple. One set of named parameters is enough.
Can we make height, width, depth default and deprecate 1,2,3? It's always useful to have as much semantical information as possible. --Slomox (talk) 17:28, 21 April 2010 (UTC)[reply]
I removed x, y and z, but I do not think we can retire 1,2 3. We would have to run a bot to fix all the templates and we do not know if they used WxH or HxW style. Personally, I also like how much less typing thee is with the old style. --Jarekt (talk) 19:37, 21 April 2010 (UTC)[reply]
Just deprecating, they will still work. It's less typing, but on the cost of exactness. --Slomox (talk) 22:09, 21 April 2010 (UTC)[reply]

diameter[edit]

There are quite many circular objects, for which the current template is not really appropriate. Can a "diameter" option be added, or should a new template be created ?--Zolo (talk) 18:44, 3 September 2010 (UTC)[reply]

I changed the template. "{{size|cm|diameter=23}}" now renders as "diameter: 23 cm (9 in)
dimensions QS:P2386,23U174728
". So far it works for 'en' and 'nds'. Please add other languages if nobody objects to the way I implemented it.
By the way, why is there an expr in the template that adds the values of "2" and "width"? One would expect that "width" is used when both is present and "2" gets discarded. Why would anybody want to put something like "{{size|cm|12|width=12}}" resulting in "24 cm"? --Slomox (talk) 22:49, 3 September 2010 (UTC)[reply]
I fixed the issue brought up User:Slomox, it was a bad idea, but it worked if people did not mix styles.--Jarekt (talk) 04:14, 4 September 2010 (UTC)[reply]
Thanks, it seems good. Personnally, I think it would look even better if diameter was placed before the number (especially because it would avoid to have two pairs of brackets side to side in languages using centimeters + inches).--Zolo (talk) 07:12, 4 September 2010 (UTC)[reply]
@Jarekt: Thanks for fixing it.
@Zolo: Feel free to change it. --Slomox (talk) 08:56, 4 September 2010 (UTC)[reply]
Okay, I moved it to the first place. Was the </nowiki> a typo ? I removed it.--Zolo (talk) 09:10, 4 September 2010 (UTC)[reply]
It wasn't a </nowiki>, it was a <nowiki/> ;-) It's the shortened version of <nowiki></nowiki> and it's purpose was to make the leading whitespace part of the string (leading whitespaces are otherwise stripped). Similar to your use of &nbsp; (but with a breaking space instead of a non-breaking space). --Slomox (talk) 09:24, 4 September 2010 (UTC)[reply]
Okay, interesting to know this kind of things--Zolo (talk) 11:59, 4 September 2010 (UTC)[reply]

Pixels[edit]

Would it be useful to also allow sizes with pixels as a unit? See e.g. the other versions section at File:Mona Lisa.jpg. --Slomox (talk) 21:18, 4 September 2010 (UTC)[reply]

Pixels do not need conversions between metric and English units, so it is as easy to just type it. Unless the purpose is to translate word "Pixels". I do not have much problem with the expansion but also do not see much benefit. By the way translatewiki.net has translated "Unit-pixel". If I can only figure out how to use it... --Jarekt (talk) 01:28, 5 September 2010 (UTC)[reply]
We should have translations for this already since "pixels" is under every image, but unfortunately they put it all together. As for "px", you don't need to worry about translatewiki, when we have it locally: MediaWiki:Unit-pixel. Just use {{int:unit-pixel}}. Rocket000 (talk)
The benefits are being able to localize the word "pixels" and also to localize the numbers. So {{Size|px|1024|768}} would be rendered as "१,०२४ × ७६८ पिक्सल" in Hindi. --Slomox (talk) 09:16, 6 September 2010 (UTC)[reply]
So should we add it? The first use could be at Template:Artwork/doc#Multilingual_example … --Marsupium (talk) 23:55, 22 September 2013 (UTC)[reply]

height and co[edit]

I very well understand that it is more convenient that {{size|cm|5|7}} yields 5*7cm without indicating whether it is length*height or the other way round or whatever. Yet if it does not make the template awfully complex, it would be a good thing to be allowed to write {{size|cm|height=7}} and get "height: 5cm". In some cases it is not at all obvious what the size is referring to (see File:British Museum Royal Gold Cup.jpg for example).--Zolo (talk) 19:13, 9 October 2010 (UTC)[reply]

Well, for two-dimensional objects, it's understood to be width × height (at least in English). Same as our [[File:]] syntax. "Length" usually refers to whichever is the longest dimension in a 3D object, but one measurement alone is completely ambiguous. Rocket000 (talk) 05:36, 12 October 2010 (UTC)[reply]
So maybe we could add a "part measured" parameter or something like that, so that {{size|cm|measured=height|22}} would yield "height: 22cm", and {{size|m|measured=wingspan|15}}" wingspan: 15m" ? --Zolo (talk) 14:17, 12 October 2010 (UTC)[reply]
I like your first idea. |height=22 or |wingspan=15 is easier to use. Rocket000 (talk) 17:15, 12 October 2010 (UTC)[reply]
It would be simpler to use, but I think it would be less flexible. "Measured=" would allow to have things like "measured=from left toe to right hear" whereas as far as I understand, we could not get that using the other method - unless we have "from left toe to right hear" parameter hardocded in template:size. We can also leave "from left toe to right hear" out of the template but it does not seem optimal for bots or maintenance. --Zolo (talk) 09:08, 13 October 2010 (UTC)[reply]
I like |height=22 or |wingspan=15 better too it is less convoluted. As for the idea of template output identifying which dimension is height and which width or length. This would be good to identify but it would need translations to many languages and it would make this simple field more crowded. See also discussion above. Another idea proposed by Slomox was to use symbols like : |, --, /. We can also use some special graphics, something like: . --Jarekt (talk) 13:13, 13 October 2010 (UTC)[reply]
Does anyone has an idea about the code we should have for wingspan and other non height-lenth-width parameters. It could be done like diameter: included in the "x" at {{Size}} and added at the beginning of {{Sisze/en}} but if we get many parameters, it will be hard to maintain on a multilingual basis, and it also create funny texts if the template used incorrectly (size|cm|diameter=3|height=5 gives: "height: 5 cm (1.9 in); diameter: 3 cm (1.1 in)
dimensions QS:P2048,5U174728
dimensions QS:P2386,3U174728
)"--Zolo (talk) 21:04, 27 October 2010 (UTC)[reply]

Height known only[edit]

Hi, in File:Bundesverwaltungsamt - Zentrale Köln - Skulptur von Erwin Heerich (7534-36).jpg the height of the sculpture is known only. Now it looks a bit weird: 0 × 630 cm (0,00 × 248,03 in). Any idea how to fix this? Raymond 12:07, 11 October 2010 (UTC)[reply]

{{Size|cm|630}} will give "630 cm (20.6 ft)". I would prefer to do the same with height= parameter but as you mentioned it does not work optimally for that purpose. --Jarekt (talk) 02:05, 12 October 2010 (UTC)[reply]

Sorting by surface/volume[edit]

To make the dimension column at Creator:Berthe Morisot/works sortable, I was wondering if we could add surface or volume to this template. That would be wrapped in <span style="display:none"></span> tags and placed before the output, similar to the code used in this list. We could probably multiply the dimensions without converting them.  Docu  at 18:14, 24 October 2010 (UTC)[reply]

I thing that would be fine. Can you show the code changes you were thinking about? --Jarekt (talk) 04:03, 25 October 2010 (UTC)[reply]
Something like Template:Size/sandbox. It probably needs padding and it isn't that intuitive to sort by surface. Maybe just a zero padded version of the first dimension would do.  Docu  at 19:28, 25 October 2010 (UTC)[reply]
I added it to Template:Size/Unit instead and with scaling based on units. But I am not sure if it works correctly, but you can edit it yourself, since that template is not protected. --Jarekt (talk) 03:09, 27 October 2010 (UTC)[reply]
To sort (10,4,3) as (3,4,10) rather than (10,3,4), the output needs to be (03,04,10).
At least for tables, one might want to assume that they mostly use the same units.  Docu  at 05:51, 27 October 2010 (UTC)[reply]
Paintings seem to be using both metric and British units, that is why I added unit conversion. Docu you lost me, in you previous post. Please tweak Template:Size/Unit yourself as needed. --Jarekt (talk) 18:45, 27 October 2010 (UTC)[reply]
In this list, you will notice that all values are padded with leading 00000s. This is probably due to the fact that the sorting is done as text rather than as number. BTW, I'm not sure how to add that in the MediaWiki template language.  Docu  at 00:30, 28 October 2010 (UTC)[reply]

new version proposal[edit]

I have created another version of the template that separates explicit "length", "height" and "depth" from "x", "y" and "z" at {{Size/sandbox}}. It gives more choice and fixes some problems. {{size/sandbox|m|height=78|length=33}} gives "length: 33 m (36 yd); height: 78 m (85.3 yd)

dimensions QS:P2043,33U11573
dimensions QS:P2048,78U11573

" rather than the current "length: 33 m (36 yd); height: 78 m (85.3 yd)

dimensions QS:P2043,33U11573
dimensions QS:P2048,78U11573

".

It also make it possible to add new parameters like "wingspan" or "distance" in a more logical way.

I wish I had made something easier to maintain but I could not figure out how to do. Do I replace the current template by the new version ? It just needs to be translated. --Zolo (talk) 20:30, 11 November 2010 (UTC)[reply]

If nobody objects to it, I replace the template this week-end.--Zolo (talk) 22:20, 18 November 2010 (UTC)[reply]

examples:

code current en current fr proposed
{{size|mm|22}} 22 mm (0.86 in) 22 mm 22 mm (0.86 in)
{{size|cm|22|44}} 22 × 44 cm (8.6 × 17.3 in) 22 × 44 mm 22 × 44 cm (8.6 × 17.3 in)
{{size|in|11|22|44}} 11 × 22 × 44 in (27.9 × 55.8 × 111.7 cm) 11 × 22 × 44 pouces (27,9 × 55,8 × 111,7 cm) 11 × 22 × 44 in (27.9 × 55.8 × 111.7 cm)
{{size|units=m|width=22|height=44}} height: 44 m (48.1 yd); width: 22 m (24 yd)
dimensions QS:P2048,44U11573
dimensions QS:P2049,22U11573
hauteur : 44 m ; largeur : 22 m
dimensions QS:P2048,44U11573
dimensions QS:P2049,22U11573
height: 44 m (48.1 yd); width: 22 m (24 yd)
dimensions QS:P2048,44U11573
dimensions QS:P2049,22U11573
{{size|km|width=22|height=44|depth=88}} height: 44 km (27.3 mi); width: 22 km (13.6 mi); depth: 88 km (54.6 mi)
dimensions QS:P2048,44U828224
dimensions QS:P2049,22U828224
dimensions QS:P5524,88U828224
hauteur : 44 km ; largeur : 22 km ; profondeur : 88 km
dimensions QS:P2048,44U828224
dimensions QS:P2049,22U828224
dimensions QS:P5524,88U828224
height: 44 km (27.3 mi); width: 22 km (13.6 mi); depth: 88 km (54.6 mi)
dimensions QS:P2048,44U828224
dimensions QS:P2049,22U828224
dimensions QS:P5524,88U828224
{{size|ft|width=33|prec=1}} width: 33 ft (10 m)
dimensions QS:P2049,33U3710
largeur : 33 pieds (10 m)
dimensions QS:P2049,33U3710
width: 33 ft (10 m)
dimensions QS:P2049,33U3710
{{size|yd|height=33|prec=3}} height: 33 yd (30.175 m)
dimensions QS:P2048,33U482798
hauteur : 33 yards (30,175 m)
dimensions QS:P2048,33U482798
height: 33 yd (30.175 m)
dimensions QS:P2048,33U482798
{{size|mi|depth=33}} depth: 33 mi (53.1 km)
dimensions QS:P5524,33U253276
profondeur : 33 miles (53,1 km)
dimensions QS:P5524,33U253276
depth: 33 mi (53.1 km)
dimensions QS:P5524,33U253276
{{size|mi| |33}} 33 mi (53.1 km) 33 miles (53,1 km) 33 mi (53.1 km)
{{size|mi|0|33}} 33 mi (53.1 km) 33 miles (53,1 km) 33 mi (53.1 km)
{{size|mi|33|0}} 33 mi (53.1 km) 33 miles (53,1 km) 33 mi (53.1 km)
{{size|in|diameter=12|33}} 33 in (83.8 cm) 33 pouces (83,8 cm) 33 in (83.8 cm)
I like this new version, but I think there are still some issues to fix:
  1. several unit conversions are broken in the new version
  2. in the old style we used width × height × depth order I think we should use the same order in the new style for consistency.
I also think we could use more testing examples. --Jarekt (talk) 03:01, 19 November 2010 (UTC)[reply]
  1. Could you indicate which units are broken ? I have fixed typos with diameters in the templates, and two other typos in the examples.
  2. I changed the order (length-width-heigth-depth-diameter). That said, as of now the template is mostly used for artworks where height is generally given before width.
I have added cases with zeros, they are those that cause most problems.--Zolo (talk) 10:23, 19 November 2010 (UTC), edited:--Zolo (talk) 10:46, 19 November 2010 (UTC)[reply]
I have added tbe French version (no imperial units displayed). It works (fallback can't be activated in the test, you need to change the page language to see it). Is it okay now ? I can't think of other relevant example.--Zolo (talk) 10:02, 26 November 2010 (UTC)[reply]
It looks good to me. --Jarekt (talk) 21:43, 26 November 2010 (UTC)[reply]
I have uploaded the new version, but there is a problem with languages. I had not thought of paying much attention to it because I did not inted to change anything. But the lang parameter seems to be broken catalan version does not work at all (see here) while it should work exactly like French. Any idea of what went wrong ? --Zolo (talk) 09:58, 27 November 2010 (UTC) [reply]
{{Size/sandbox3}} has a LangSwitch for English and French, so for any languague other than French it works always in English. It does not call {{Size/ca}} at any time (I think, not sure at all). --V.Riullop (talk) 10:13, 27 November 2010 (UTC) [reply]
Oops! yes thanks I had forgotten to replace test3 by unit it works now.--Zolo (talk) 10:45, 27 November 2010 (UTC)[reply]


I have updated the template, except the Basque and the Low German, for which Google translate did not really work (I know I coud have used a real dictionary). Please check the translations.
It would be easier to update, and it could be made customizable if we had a international labels for "width" "height" etc. and various pages for different styles rather than different languages (ie. a metric/imperial page that would be used by default on the English template, a metric only page for most European languages etc.) I don't know exactly how it could be done, and whether it would make the template much more complex.--Zolo (talk) 11:31, 27 November 2010 (UTC)[reply]

reorganization[edit]

I have changed the organization in the test pages to avoid useless repetitions in different language pages. Dimension labels ("height", "length" etc.) are now all at the same page ({{Size/sandbox5}}). It does not change the output (see test cases above) but it should be easier to maintain. More changes shoud probably be done (eg, internationalize unit names), but it is a first step. Can I change the real template ?--Zolo (talk) 22:33, 13 January 2011 (UTC)[reply]

translatewik[edit]

Having one version of the template per language makes it very hard to maintain. Should I wait a while for new parameters proposals and then switch to a system with translatewiki labels or something like that ?--Zolo (talk) 07:19, 17 December 2010 (UTC)[reply]

What words would you like translated?--Jarekt (talk) 13:38, 17 December 2010 (UTC)[reply]
length, height, width, depth and diameter at least. Possibly others if they can be useful.--Zolo (talk) 14:39, 17 December 2010 (UTC) Unit names also need to be translated in some languages. Possibly we already have that somewhere, I don't know.--Zolo (talk) 15:10, 17 December 2010 (UTC)[reply]
We could use {{LangSwitch}} either within {{Size}} or in some other template(s). Also height (⧼Gm-height⧽) and width (⧼Gm-width⧽) are already at translatewiki and probably can be used. --Jarekt (talk) 21:03, 17 December 2010 (UTC)[reply]
We currently have two veresions of the template: one that displays metric+imperial (en, pl, de) and one that displays metric only (other languages). I think we can either
  1. replace size/en size/es etc. by size/output, add a first {{langSwitch |de|en|pl=content of the current English page + langSwitches insdide |ca|es|fr|etc. content of the current Spanish page + langSwitches}}
  2. create a size/metricimperial that would be the default for de, en and pl and a size/metric that would be the default for other languages. If it happens that we need to override the default (for example add imperial for all languages), this option may offer more flexibility.--Zolo (talk) 09:04, 18 December 2010 (UTC)[reply]
Sounds like a good idea It should make it more readable. By the way definitely Polish and most likely German versions do not need imperial units. --Jarekt (talk) 03:26, 14 January 2011 (UTC)[reply]
That's what thought, I'll correct it.--Zolo (talk) 09:50, 14 January 2011 (UTC)[reply]
Two more things: {{Size}} does not seem to do anything at the moment except pass parameters to {{Size/units}}. May be we can merge them together and remove one layer. Also maybe we can create {{Size/label}} where we will keep all LangSwitch codes to translate: length, height, width, depth and diameter. --Jarekt (talk) 03:38, 14 January 2011 (UTC)[reply]
Yes, removing merging units with the input page and creating a label page seems a good idea. But there is one thing that I had forgotten to take into accoutt: it seems likely that some languages put the unit before the figure ("mi 18"). In terms of code length, I think the best solution would be a page that would provide the regular layout for each language:
{{langSwitch
|en|fr={{#if: {{{dimension|}}} | {{dimension}}}{{int:colon}} }} {{{figure|}}} {{{unit|}}} 
|some language={{{unit|}}} {{{figure|}}} {{{dimension|}}}
}}

But that would mean one more page.--Zolo (talk) 09:50, 14 January 2011 (UTC)[reply]

Newer version[edit]

I have reworked on the template (testcases in the table above). New changes are:

What still needs to be done:

  • Error handling
  • Rounding: when I try to use round I either get error messages or it displays "2.29392I9 round 2".--Zolo (talk) 08:30, 21 January 2011 (UTC)[reply]
  • Minor problem: {{int:colon}} is supposed to give a space plus a colon but it doesn't give the space here.
The proposed system uses as many pages by language as the current one + the two label pages and is probably on bit more expensive for the server. However the whole code is much shorter and I think it is easier to maintain and expand. Thoughts ?--Zolo (talk) 08:30, 21 January 2011 (UTC)[reply]
I corrected my errors with "round", I think the test is now better than the current version, do I upload it ?
{{Title without disambig}} and {{Title disambig text}} make it possible to add additional text. {{size|cm|length=22 (maximum)}} could give "length: 32 cm (maximum)". However it would lead to substantial efficiency loss. Since Commons image description are fairly short, speed may not be as much of a concern here as in Wikipedia, so do I use it?
I think it is fine. I would combine {{Size/dimension label}} and {{Size/unit label}} into single template, but current way is fine too. --Jarekt (talk) 05:00, 5 February 2011 (UTC)[reply]
I have uploaded the new version. Template:Size/testcases is rather slow to load for me right now, I hope it is not related to the template. If so maybe it is better to go back to the previous version.
I have not merged {{Size/dimension label}} and {{Size/unit label}} because the pages had already been created but it can be changed
It would be much more readable to if we could have a for each parameter: "parameter name" size unit, but I don't see how to do that.
If the new version is okay, I think we can delete the /lang pages.--Zolo (talk) 16:58, 5 February 2011 (UTC)[reply]

prec[edit]

Can I set the precision to 1 ? From what I can see, the input is virtually always at prec 1 or 0
"3 cm (1.1 in)" looks a bit strange to me.--Zolo (talk) 08:28, 14 February 2011 (UTC)[reply]

Sounds fine to me. --Jarekt (talk) 13:37, 14 February 2011 (UTC)[reply]

 Not done Actually the millimeter to inch conversion results in large loss of precision and I don't know what to do.

✓ Done except for mm. The code is rather ugly but I think the output looks more logical.--Zolo (talk) 09:43, 15 June 2011 (UTC)[reply]
I have also removed prec when no conversion is done. I suppose that it is more usable to let the user implicitly choose the precision (and that it would be even better to automatically adjust the precision of conversion but I don't know if we can do that)--Zolo (talk) 02:38, 19 July 2011 (UTC)[reply]

Delete language pages[edit]

If the template is okay, can we delete the /lang pages to avoid this ?--Zolo (talk) 21:47, 18 February 2011 (UTC)[reply]

✓ Done I also merged 2 label subpages into single /label; moved hu and it translations to /label. --Jarekt (talk) 04:06, 19 February 2011 (UTC)[reply]
Ok thanks--Zolo (talk) 09:43, 19 February 2011 (UTC)[reply]

Broken[edit]

Somehow somebody broke the template for language set to "nds". It still worked the last time I touched the template. Please fix it. --Slomox (talk) 11:09, 3 March 2011 (UTC)[reply]

Apparently this was caused by the combination of {{GetFallback2}} and {{LangSwitch}}: nds-nl and pdt were broken too (dimension labels fell back to nds but the rest was blank). I have no idea of what was going on but I have already noticed that strange things can happen with {{GetFallback2}}. I have removed the {{LangSwitch}}, I don't see any other solution. I hope it works now--Zolo (talk) 12:21, 3 March 2011 (UTC)[reply]
Actually I hadn't realized than a langSwitch with default is essentially an expensive synonym of {{#switch: {{int:lang}}--Zolo (talk) 16:40, 5 March 2011 (UTC) (er no not exactly)[reply]
If "combination of {{GetFallback2}} and {{LangSwitch}}" is broken than we need to fix {{GetFallback2}} and/or {{LangSwitch}}. There is no need to stop using {{LangSwitch}}. --Jarekt (talk) 01:55, 9 March 2011 (UTC)[reply]
I just notice removal of {{LangSwitch}} from {{Era}} and possibly other templates. That will break the fallback mechanism, created for many languages. Please undo and if something is not working with {{LangSwitch}} than lets fix it. Can you create in sandbox an example of an issue you are trying to fix? --Jarekt (talk) 05:16, 9 March 2011 (UTC)[reply]
I had just replaced the langSwitch {{Era}} by a switch+please translate because I tried to reduce the depth of other date (admittedly this was silly since most other date don't use era). LangSwitch works, it is just that it increases template length as can be seen in user:Zolo/test
There sometimes seems to be a problem with langSwitch for languages in {{GetFallback2}}, but I don't quite get what happens.--Zolo (talk) 07:09, 9 March 2011 (UTC)[reply]
I like user:Zolo/test - it shows a definite problem. We seem to be operating most of the time very close to the maximum depth allowed, and little innocent changes can get us over the limit. I wonder who sets the limit. May be we should create a Help page gathering all the information about the template depth and the transclusion limits. I see it sometimes but do not know much about it. As for issues with {{GetFallback2}} we would need a reproducible error before we start fixing it. I did some tests here but I did not push the depth limit. --Jarekt (talk) 13:48, 9 March 2011 (UTC)[reply]
I think I found and fixed the real source of the problem. The rewrite of {{LangSwitch}} was faulty. The faulty code was the one line that is called when {{GetFallback2}} is called and the second fallback is not applicable. In that case the template didn't call {{{default|}}} but instead {{{{{{default|}}}|}}}. That means if you called {{size|cm|12|lang=nds}} it wouldn't default to "cm" but instead to "{{{cm|}}}" which of course is undefined.
Zolo, please check whether we should revert the edits you made trying to fix the problem. Perhaps you addressed other issues in them which I am not aware of, so I don't want to revert them myself. But if you didn't it probably is better to revert them completely (it's easily possible to introduce unexpected side-effects with edits and we probably fare better when we only keep edits that really were necessary). --Slomox (talk) 14:37, 9 March 2011 (UTC)[reply]
Yes it seems to work now, thanks. I have reverted my edits but actually a switch may be more flexible (and cheaper) than a langSwitch at template;size/layout

@Jarekt, there are some things about transclusion at meta:help:Expansion depth and at w:Wikipedia:Template limits. Apparently large templates substantially affect performance of long Wikipedia pages. I imagine it is not such a concern for Commons but I don't see any hint to customize the limit (and there are proposals to pool templates, which probably would make customization all but impossible).--Zolo (talk) 16:36, 9 March 2011 (UTC)[reply]

Height or width inconsistencies[edit]

1. Inconsistency in this documentation Template:size/doc: The introduction for this template says "Displays a 1D (length), 2D (width × height) or 3D (width × height × depth) size", but the source of the definitions of the parameters says:

|2=2
|2d=One dimension measured without explicitly mentionning what. It should be used for the height of paintings, among other cases. 
|2def=
|2stat=Another dimension measured  without explicitly mentionning what, for example the width of paintings.
|3=3
|3d=A second dimension measured (width in the case of paintings)
|3def=
|3stat=optional

the value for 2dstat should clearly be optional. Was the incorrect value an attempt to reverse "height" and "width" here? At present the displayed documentation clearly requires (height × width) for 2D and is not very explicit about the assignment with a third dimension.

2. As a triviality, anyone clarifying this could correct the spelling of mentioning. It does not seem worth an extra edit just for that.

3. Looking at Template:Artwork/doc (better to deal with both at the same time). This has the same description as here but confusing examples::

"Dimensions of the artwork: 1D (length), 2D (width × height) or 3D (width × height × depth). Please use {{Size}} formatting template, such as:
  • {{Size|unit=cm|width=76.7|height=83.5}} <— gives height: 83.5 cm (32.8 in); width: 76.7 cm (30.1 in)
    dimensions QS:P2048,83.5U174728
    dimensions QS:P2049,76.7U174728
  • or {{Size|in|30.2|32.87}} <— gives 30.2 × 32.8 in (76.7 × 83.4 cm), if sizes are given in inches"

In the first bullet, the values are labelled correctly but appear expanded in the reverse order to the unlabelled ones in the second expansion.

4. The French text in Template:Artwork/doc says "Dimensions de l'œuvre : 1D (longueur), 2D (hauteur × largeur) ou 3D (largeur × hauteur × profondeur)." Is that swapping between the dimensions for 2D in different languages supported by the internationalisation or is that another problem in the documentation? Is the swapping of the order between 2D and 3D correct in French?

I think that I have probably got some of my usages of the size template the wrong way round. Please can we clarify the documentation before I start checking? --Mirokado (talk) 13:52, 27 July 2013 (UTC)[reply]

If you know which dimension is height and which is width than you should use "height" and "width" parameters. "2", "3", "4" are leftovers from the earlier versions of the template. The images using "2" & "3" parameters do it very inconsistently so sometimes it is "with x height" and sometimes "height x width". That is often because those numbers are copied from somewhere that is inconsistent. --Jarekt (talk) 02:42, 28 July 2013 (UTC)[reply]
Thanks. Good points and clear explanation. Can we update the documentation to say that? --Mirokado (talk) 00:24, 29 July 2013 (UTC)[reply]
I did some minor corrections to the documentation, but please feel free to make it clearer. --Jarekt (talk) 03:24, 29 July 2013 (UTC)[reply]
That is much better now. Thanks for the quick response. --Mirokado (talk) 22:41, 29 July 2013 (UTC)[reply]

Internationalisation[edit]

Hello,

I see that Template:Size/label lacks many languages, as is only normal. But this information is available a Wikidata, and could be obtained with a simple call to the label of the relevant Q-items. For instance, mw.wikibase.label( "Q208826" ) will return the word for "height" in the language used by the user, and will do so in 79 languages instead of the 30 supported by Template:Size at the moment.

Would you be interested in switching to such a system (pinging User:Jarekt, User:Zolo) ? Rama (talk) 10:27, 26 January 2018 (UTC)[reply]

Using Lua would really make sense for this template, and we could use Wikidata label by the same occasion. I'll try to do it if no one else does it (though it's been a couple of years I have thought of doing it and done nothing).Zolo (talk) 11:33, 26 January 2018 (UTC)[reply]
I would be glad to do it, but if there were procedures in place for such things I'd just prefer avoiding stepping on somebody's toes or doing something untowards on a widely-used template. Rama (talk) 12:30, 26 January 2018 (UTC)[reply]
We could just replace some {{LangSwitch}} templates in Template:Size/label with {{Label}}. That would only take minutes and I can do it. We could also rewrite the template using Lua, so it would be compatible with fetching that data from Wikidata. Such rewrite would be a prerequisite to rewriting {{Artwork}}. I just wrote Module:NationAndOccupation and Module:Size could have similar structure. However if some tries to write Module:Size please set up comprehensive testing pages, like testcases and test results, so others can verify the correctness of the code. --Jarekt (talk) 13:04, 26 January 2018 (UTC)[reply]
Regarding a rewrite of {{Artwork}}, I was considering it as a spin-off of my tentative rewrite of {{Category definition: Object}} which you can see at User:Rama/Catdef (example of usage: Category:The Seated Scribe). The module used in this is a horrible draft in dire need of rewrite, but it is mostly functional. I would be very interested in tips and help to make it ready for production and wider use (my appologies if you've already heard this). Rama (talk) 13:50, 26 January 2018 (UTC)[reply]
It's true that we can simply add Wikidata label as a default when no translation is provided. No need for Lua for that. However, Template:Size looks really contrived relative the the simple task it and it seems hard to fix using Wikicode, so a Lua rewrite may make sense. I had forgotten that Module:Size looked mostly functional, though I am open to organize it differently.
I had taken a shot at a rewrite of template:Artwork in Lua that would make it easier to include Wikidata. That's Module:Artwork. It may not be the best way to do it, but it seems to mostly work (testing to be completed). However, I am stuck with this embedded wikitable issue shown on Module talk:Artwork. --Zolo (talk) 14:10, 26 January 2018 (UTC)[reply]
I have replaced some of the {{LangSwitch}} as suggested by Jarekt, it seems to mostly work. I am a bit disappointed that there are not Japanese labels for all dimensions, but at least some do show up. Rama (talk) 15:48, 26 January 2018 (UTC)[reply]
Thanks, Rama. If we have some of the translations and Wikidata does not than we can provide them. --Jarekt (talk) 15:54, 26 January 2018 (UTC)[reply]

Rewrite in Lua[edit]

Under closer inspection this template had a lot of issues: lang parameter stopped working and some units like nm and um did not work correctly. I rewrote the template in Lua, using Module:Size. Please report any issues. --Jarekt (talk) 04:46, 2 March 2018 (UTC)[reply]

In case of English this template shows units in metric and imperial units. In the past {{Size}} had fixed unit pairs, like cm and inches, so input in inches always resulted in second number in cm and vice versa. In the current implementation I tried to pick units as to have "nice" numbers. The nice number was designed to give such units that the number is the smallest number bigger than 1. There was criticism of this approach as it occasionally gave cm-feet pairing. I tweaked "nice" numbers to be bigger than 10. --Jarekt (talk) 14:34, 15 March 2018 (UTC)[reply]
Thanks for the cm to inches instead of feet conversion. https://commons.wikimedia.org/wiki/File:Giovanni_Segantini_-_The_Punishment_of_Lust_-_Google_Art_Project.jpg correctly converted the mm height to inches, but not the mm width, so I changed both to cm.Mabrndt (talk)

depth[edit]

Depth is linked to the wrong wikidata item. It should be linked to Q3250078. Vincent Steenberg (talk) 21:11, 28 March 2018 (UTC)[reply]

Vincent Steenberg, It seems like both {{Size}} and Wikidata defines dimension called "depth". On Wikidata it is only meant as vertical depth, as in a depth of a lake, and in {{Size}} it is not precisely defined so it can mean vertical depth and horizontal depth, (horizontal dimension away from the observer). I was looking at old translations of the term in Template:Size/label and at least in Polish term "Głębokość" mostly mean vertical depth but would be still understood if used as horizontal dimension. Maybe we should loose links to wikidata and use Q3250078 for translation if it is a local variable, but also use Q930412 if the number comes from Wikidata. --Jarekt (talk) 12:46, 17 May 2018 (UTC)[reply]
That's a good idea. Thank you. Regards, Vincent Steenberg (talk) 15:52, 17 May 2018 (UTC)[reply]

"Lua error in Module:Size at line 180: attempt to concatenate local 'unit' (a nil value)."[edit]

Hello, the above error is showing on all pages where this template is being used. Opencooper (talk) 07:21, 17 May 2018 (UTC)[reply]

Fixed and thanks for reporting. --Jarekt (talk) 12:07, 17 May 2018 (UTC)[reply]

Lua error in Module:Wikidata_label at line 49: attempt to index local 'entity' (a nil value).[edit]

See what happens here: {{Size|unit=mi|width=10|height=20|depth=30}} -> height: 20 mi (32.1 km); width: 10 mi (16 km); depth: 30 mi (48.2 km)

dimensions QS:P2048,20U253276
dimensions QS:P2049,10U253276
dimensions QS:P5524,30U253276

. --Arnd (talk) 13:09, 18 May 2018 (UTC)[reply]

Fixed See here. --Jarekt (talk) 16:38, 18 May 2018 (UTC)[reply]

Calculating error[edit]

Hello! There might be an error...

  • 1,016 × 538 mm (40 × 21.18 in) with 1016 and 538
  • 538 × 1,016 mm (21.18 × 40 in) with 538 and 1016
  • 1,040 × 2,050 mm (40.94 × 80.70 in) with 1040 and 2050
  • 1,000 × 1,234 mm (39.37 × 48.58 in) with 1000 and 1234

Please have a look. Thank you. --XRay talk 11:02, 29 May 2018 (UTC)[reply]

XRay, I think, I Fixed it . Please verify. Interesting the problem mostly occurs in German, ass the above examples shown just fine in English, Polish, etc. --Jarekt (talk) 15:00, 29 May 2018 (UTC)[reply]
The examples above are OK now - in German. Thank you. --XRay talk 15:42, 29 May 2018 (UTC)[reply]
And in Germany we have a decimal comma, not a decimal point. And a point as thousands seperator instead a comma. May be that's the reason. IMO there are other countries with a different behaviour. --XRay talk 15:46, 29 May 2018 (UTC)[reply]
Yes that was the source of the bug, but I think it also had potential to mess up in other cases. --Jarekt (talk) 16:12, 29 May 2018 (UTC)[reply]

improvements[edit]

I just made this template a bit smarter, so in case of unnamed dimensions of 2D artwork it compares painting size to file sizes and names dimensions accordingly. Images there that technique was used are added to Category:Size templates with unnamed dimensions. The only drawback is when metadata is for a full image but the image shows only a fragment of the artwork. I try to detect that case, but one can easily construct a case which will full the algorithm. --Jarekt (talk) 20:08, 20 June 2018 (UTC)[reply]

@Jarekt: That was a good idea, thanks! But why populate a category with these cases? Category:Size templates with unnamed dimensions is currently huge (~115k). If I understood it correctly this is not a maintenance category, since there's nothing wrong with the use of {{Size}} with unnamed parameters. I suggest dropping this category. —capmo (talk) 14:28, 1 October 2021 (UTC)[reply]
capmo you are right I totally forgot about Category:Size templates with unnamed dimensions and no longer have plans for it, so I stop adding it. --Jarekt (talk) 12:48, 2 October 2021 (UTC)[reply]

New parameter "applies to part"[edit]

  • Looking at Category:Artworks with Wikidata item missing dimensions I think we need a new |applies to part= parameter corresponding to applies to part (P518) with a controlled list of options. Currently it is difficult to give this information in a clean i18n-friendly way.
  • We already have {{With frame}} and {{Frame dim}} with each ~150 transclusions which are only term translations.
  • But (for good reason) Template:Artwork/doc advises "Avoid using Language templates" for its "dimensions" field!
  • This query (~30s) shows the number values of applies to part (P518) to dimension properties are used in the wild (same query broken down by property). The majority of them is not justified I think as they aren't a part but the whole object, but picture frame (Q860792) (~1700 uses) is justified and we should offer this here too. I propose that we use Module:I18n/objects/data as a list of allowed values.
  • Giving this parameter should allow to give more than one set of dimensions. So current
    {{size |unit=cm |height=96.2 |width=73 |depth=3}};<br> {{with frame| {{size |unit=cm |height=123.5 |width=100.5 |depth=12}} }}
    from here could be rewritten as
    {{size |unit=cm |part1=image area |height1=96.2 |width1=73 |depth1=3 |part2=frame |height2=123.5 |width2=100.5 |depth2=12}} }}
    and should then display something like (in en-GB):
    "image area: Height: 96.2 cm; Width: 73 cm; Depth: 3 cm ;
    frame: Height: 123.5 cm; Width: 100.5 cm; Depth: 12 cm"
    (changed my mind)

Thanks in advance for any comments, --Marsupium (talk) 01:54, 4 November 2018 (UTC), 02:22, 4 November 2018 (UTC)[reply]

I agree, we should make use of that property. --Jarekt (talk) 19:26, 6 November 2018 (UTC)[reply]

Capitalization of dimension labels[edit]

Could we remove the ucfirst in Module:Size? I've seen it has been there for more than 8 years. But it isn't really consistent. Any reasons for keeping it that I've missed? --Marsupium (talk) 13:35, 3 May 2019 (UTC)[reply]

I've implemented this for now. Best, --Marsupium (talk) 03:32, 28 March 2022 (UTC)[reply]

Handling of missing units from Wikidata[edit]

In d:Special:PermaLink/990844286 the unit for height (P2048) and width (P2049) is missing. This throws a script error and the whole {{Artwork}} isn't displayed. This shouldn't happen. Perhaps they should rather categorized in a category like Category:Size module usages with missing unit? Or some more general category as a subcat of Category:Wikidata related maintenance like Category:Artworks with errors at Wikidata which could also comprise other constraint violations and further investigated on the items' pages? Cheers, --Marsupium (talk) 00:35, 11 August 2019 (UTC)[reply]

Edit request: Delete the space in front of ″ (double prime/inch sign)[edit]

Greetings and felicitations. While abbreviations of units (e.g., "in", "cm") are supposed to be spaced, symbols are not—see The Chicago Manual of Style, 17th Ed., section 9.16 "Numbers with abbreviations and symbols" (p. 550). Would it be possible to eliminate this space (as exemplified in the description of John James Audubon 1826: "Height: 90.2 cm (35.5 ″); Width: 69.8 cm (27.4 ″) ")? I.e., change the affected measurements to "35.5″" and "27.4″". —DocWatson42 (talk) 09:51, 28 January 2020 (UTC)[reply]

Fixed with this edit. --Jarekt (talk) 23:24, 28 January 2020 (UTC)[reply]
Thank you. ^_^ —DocWatson42 (talk) 23:34, 28 January 2020 (UTC)[reply]