User talk:Jc86035

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
This is Jc86035’s talk page, where you can send messages and comments to Jc86035.


Welcome to Wikimedia Commons, Jc86035!

-- Wikimedia Commons Welcome (talk) 14:48, 30 July 2012 (UTC)[reply]

BSicon categories[edit]

If you are going to recategorize BSicons, please make sure that the categories actually exist (or else create them). Thank you. Useddenim (talk) 13:49, 18 February 2024 (UTC)[reply]

@Useddenim: Thanks for mentioning that. I'll check if I missed anything else. Jc86035 (talk) 14:53, 18 February 2024 (UTC)[reply]

Mass renaming concern[edit]

I have 18 files on my watchlist that you have renamed, and I'm concerned about the renaming not being evidenced anywhere in the BSicon/Catalogue#Naming logic. Specifically, I'm seeing the addition of ".LL" and ".RR" to wide shift icons, and I cannot find any justification or precedent for this. Please check the files

and any others you have applied the same renaming to, and either revert your actions if they were made in error, or bring it to the Talk:BSicon/Renaming board if you still believe it is justified. VanIsaac (en.wiki) 03:27, 24 February 2024 (UTC)[reply]

@Vanisaac: The .L and .R suffixes are already documented (although not precisely enough, I think) at BSicon/Catalogue#Suffix modifiers. They were introduced in late 2018 to cover some edge cases, although they don't seem to have been used much.
The start or end of the track is supposed to be aligned along the central axis of the icon unless specified otherwise. This also applies for double-width icons, or at least I have previously renamed icons for that reason. Some icons like   (utbvSHI5gr-~L) were renamed by me in 2020 to specify clearly where the track starts or ends. Other icons like   (uehbvv--SHI4ngnr) were renamed by me in 2018 before the .L and .R suffixes were created.
There are now three different ways to transform an object in an icon to the left or right. ~L/~R transforms an object to the left or right by half of the icon width, regardless of how wide the icon is, and the other two methods (parallel lines syntax and .L/.R suffixes) transform an icon to the left or right by a quarter of the icon height.
Typically, if multiple naming methods would work for a set of icons, the shortest or clearest method would be chosen. The other possible option for renaming   (bSHI4r.LL) would have been to use parallel lines syntax to make bvv--SHI4r, which is longer. ~L/~R wouldn't work here because the smallest transformation possible in either direction (half of the icon width) would have been twice the amount needed. This is also consistent with the naming of   (bv2SHI5r.LL), which I also renamed because it doesn't appear to have any other possible names that work within existing naming logic.
Where the repetition of a suffix changes the icon linearly, the suffix modifier is not repeated, such as in   (hdBHF~RR) or   (BHFr@FF).
I may create a new section at Talk:BSicon/Renaming in case anyone is interested (I previously proposed changes to these suffixes and the possible .l/.r suffixes in 2020 and got no response), but I am fairly sure that each of the individual components of the renaming logic used here is already established in some way. Jc86035 (talk) 05:29, 24 February 2024 (UTC)[reply]
I have a concern with that logic. The "." operator really only makes sense as a shift away from being centered, which none of the above are. That allows for symmetric shifting, and makes the shifts intuitive. For the life of me, I have no idea why you would have opposite shift directions for File:BSicon exbSHI4r.LL.svg and File:BSicon exbSHI4l.RR.svg. Please take this to the renaming noticeboard so it can be discussed before implementing any other name changes, because this seems like a change towards confusion with no commensurate benefit. VanIsaac (en.wiki) 06:06, 24 February 2024 (UTC)[reply]
@Vanisaac: I know the names you chose are simpler, but they don't fit with how shifts work outside of this specific context. Absent any modifying syntax, they start or end at the midpoint of one edge of the icon in order to connect with the previous or next row in the diagram, so   (STR) connects with   (SHI3l), and each of the lines in   (bvvSTR) would connect with   (bvvSTRl--SHI2ro). As such, as far as I can tell, bSHI4l (or bKRWl) would start at the midpoint of the top edge, just like   (KRWl) or   (dSHI4l) or   (bSHI2lr). (I think bSHI2l and bSHI2r would create bSHI2lr, but they wouldn't if they were centred horizontally.)
There isn't any real reason for double-width icons to be named with different logic to all other icons for where lines start and end, and the start/end point of the line has to be decided for odd-numbered shifts like   (bSHI5l.RR), because if you centred them exactly in the image frame they wouldn't line up with about 99.99% of icons.
The icons have opposite transformation directions because it creates shorter names. This practice already exists in icons like   (vSHI2l-) and   (v-SHI2r), which have been named like that for over 10 years. One is a shift to the left transformed to the right, and vice versa.   (v-SHI2+r) and   (vSHI2+l-) respectively redirect to each of them.
I was already drafting up a section about these suffixes on Talk:BSicon/Renaming but I'm not sure if it would make sense to focus it on the suffixes, since I think your concern specifically applies in the context of double-width icons? If we wanted to propose a change to the definitions so that your original icon names are explicitly the correct way to do it (in the context of double-width shifts or all double-width icons), that is also possible, but I personally think it would be hard to logically justify that within the existing naming system. Jc86035 (talk) 06:41, 24 February 2024 (UTC)[reply]
File:BSicon exhWHSTaeq.svg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry.

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Hattori 15 (talk) 05:26, 13 March 2024 (UTC)[reply]