Commons talk:Graphic Lab/Illustration workshop
Why was redirect converted to this?
[edit]So as to give the Illustration workshop it's own place to carry on discussions specifically relevant to the workshop. And to better allow meta topics relating to all the workshops to be addressed on the main Graphic lab talk-page. As per the notice at the top of the main talk-page. --Kevjonesin (talk) 20:35, 25 June 2013 (UTC)
- Fantastic, the Illustration workshop now has it's own talkpage, that's great, hopefully this means there won't be any more of this:
Penyulap ☏ 20:49, 25 June 2013 (UTC)
Regarding the off topic 'comment' in the preceding section
[edit]- To help those who may come by in the future I've copied threads relevant to Penyulap's 'comment' above —collapsed below:
relevant threads |
---|
-- Archiving requests -- I've reverted an edit here because too many of those requests haven't been finalised according to the requesters. The requester themselves, not an artist, needs to express satisfaction with a request before it can be archived, unless there is a wide consensus AND a significant amount of time has passed. Penyulap ☏ 05:19, 23 June 2013 (UTC)
Coat of Arms of Riga doesn't show why it's been archived for example. Penyulap ☏ 12:44, 23 June 2013 (UTC)
1st off, archiving a request that's been up for 14 months seems reasonable to me. It wasn't deleted from the wiki, it was moved to an archive where editors who might decide to take interest can still find it if they wish. Perhaps if Penyulap has something to contribute to the file she could just go ahead and do so, or if concerned for the interest of the original poster, go ahead and contact that poster to see if they are actually concerned before reverting another editor's attempt to clean up the page. Something tangible instead of hypothetical. As to dealing with the issue in general, perhaps set up a bot as we've done at the Commons Photography lab. See talk page thread and related notices on the main Photo workshop page. User:McZusatz —who helped set it up— seems quite friendly and would likely be willing to help. --Kevjonesin (talk) 17:36, 23 June 2013 (UTC) p.s.— I would generally consider it best practice to post a note to the requester's talk page encouraging them to either mark the request as "resolved" or to provide further feedback as to how it may become so before flagging it "resolved" oneself. Especially if a request has been up for less than a month or so. At the Wikipedia Photography workshop we have a handy template for such. --Kevjonesin (talk) 18:03, 23 June 2013 (UTC)
This will make it quite easy for people to make up their own mind about who's been doing the edit warring, you know, so they don't have to listen to hype and crap and so on, they can just see for themselves. Penyulap ☏ 16:41, 24 June 2013 (UTC)
-- Manual Archival in Graphics Lab -- Hi Patrick, at the GFX lab, we have to wait until the requester expresses their satisfaction with the work before archiving the request, this has always been the way. Please don't re-archive requests where the requester hasn't had a chance to make their comment, there is no need for it, and it discourages them from commenting. Remember, it's not the artists place to argue or make the requesters feel uncomfortable, patience is important. Penyulap ☏ 05:25, 23 June 2013 (UTC)
|
- --Kevjonesin (talk) 22:18, 25 June 2013 (UTC) --Patrick87 (talk) 00:35, 26 June 2013 (UTC)
Automatic archival of Graphic Lab requests
[edit]Dear Graphists,
resolved requests are slowly but steadily accumulating on our workshop pages, cluttering them needlessly and concealing requests that need our attention. Since manual archival is a tedious task it was often neglected in the past adding to the problem. I therefore propose we introduce a consistent and functional system for automatic archival of requests in all Graphic Lab workshops.
To find a solution that fits our needs best your valued input is needed. Please join the discussion at Commons talk:Graphic Lab#Automatic archival of Graphic Lab requests. Take the chance and voice your opinion! --Patrick87 (talk) 21:35, 3 July 2013 (UTC)
- Splitting up the centralised talkpage worked well didn't it. Penyulap ☏ 23:40, 3 July 2013 (UTC)
- It does it's job, but in cases like this were all workshops are involved I'm a little unsure on how to reach as most graphists as possible. I'm afraid not everybody has the Commons talk:Graphic Lab on his watchlist were the discussion is going on, and a single notification like above possibly doesn't catch enough attention. --Patrick87 (talk) 23:51, 3 July 2013 (UTC)
- That IS the job of a centralised talkpage. It was split up arbitrarily. The usual reason for such a move is to try to hide what you've been up to, like edit warring and so forth. Of course, I'd like to be corrected on that one, maybe the person who decided all by themselves to split up the pages can give us a reason why, because obviously it's not working at all. A fail. Now, it's causing useless busywork as you need to copy stuff from one page to another. Penyulap ☏ 10:30, 4 July 2013 (UTC)
- Sorry, but did you just try to blame me for something I did not even do? The splitting was done by Kevjonesin and given the facts that were present when he did it (only the Commons:GL/I talk page redirecting to the Commons:GL talk page but none of the Commons:GL/P, Commons:GL/P, Commons:GL/VS talk pages) was probably the right decision.
- If we really want a centralized discussion page the talk pages of all workshops would need to be redirected. But then again there is no place to talk about workshop specific issues. Also this does not solve the problem that the centralized discussion page has only few watchers, it will make it even harder to reach graphists, since one can't even post a short notice as I did above. --Patrick87 (talk) 11:41, 4 July 2013 (UTC)
- Why can't you post a short notice like you did above ? did it work ? I don't get it, it looks like it worked, I can read it. Penyulap ☏ 12:59, 4 July 2013 (UTC)
- I can (now that we don't redirect and have separate talk pages), but I wouldn't be able to do so if we redirected all workshop talk pages to the centralized talk page --Patrick87 (talk) 13:21, 4 July 2013 (UTC)
- well is it working ? looks like there are less people watching this page than watching the main page. Penyulap ☏ 14:03, 4 July 2013 (UTC)
- I did not say it was working (actually I said "I'm afraid [the notification] possibly doesn't catch enough attention"). But it's at least better than nothing.
- Your're wrong with your assumption that more people would watch the main page. Commons:GL is watched by only 67 people whereas Commons:GL/I is watched by 110 people. And you have to remember that this number even grows when you add the people watching the other workshops. --Patrick87 (talk) 14:18, 4 July 2013 (UTC)
- well, I'm glad you're happy to chatter on with these dead accounts with a Ouija Board, but the thing is they don't count at all in gathering a consensus. For actual people, this page has less commenters than the more central discussion, so it's a fail. Well, not so much in the spirit world of course, it's awesome there, but in the real world it's a fail. Penyulap ☏ 15:57, 4 July 2013 (UTC)
- Sorry, its impossible for me to follow your reasoning. You're basically saying if we redirected all workshop talk pages to Commons talk:Graphic Lab we'd magically reach more people than we do now? That doesn't make any sense at all.
- Anyway this discussion is unlikely to catch the attention of further graphist regarding the initial proposal, so its pointless anyway. --Patrick87 (talk) 16:26, 4 July 2013 (UTC)
- well, I'm glad you're happy to chatter on with these dead accounts with a Ouija Board, but the thing is they don't count at all in gathering a consensus. For actual people, this page has less commenters than the more central discussion, so it's a fail. Well, not so much in the spirit world of course, it's awesome there, but in the real world it's a fail. Penyulap ☏ 15:57, 4 July 2013 (UTC)
- well is it working ? looks like there are less people watching this page than watching the main page. Penyulap ☏ 14:03, 4 July 2013 (UTC)
- I can (now that we don't redirect and have separate talk pages), but I wouldn't be able to do so if we redirected all workshop talk pages to the centralized talk page --Patrick87 (talk) 13:21, 4 July 2013 (UTC)
- Why can't you post a short notice like you did above ? did it work ? I don't get it, it looks like it worked, I can read it. Penyulap ☏ 12:59, 4 July 2013 (UTC)
Following the discussion linked in my initial comment I set up automatic archiving by User:SpBot on all Graphics Lab workshops today. SpBot will automatically archive sections which are marked with {{Section resolved}}. Therefore in future:
- Please mark requests which are resolved satisfactory with
{{section resolved|1=~~~~}}
Remember to put your signature (~~~~) there, since it contains a timestamp (which is needed by the bot). The template we used so far ({{resolved}}) is not necessary anymore. - After the template is applied the bot will wait 30 days before archiving the section. This will allow other editors to review the changes and to reopen the request (by removing the template) in case of any problems that were not yet solved completely.
--Patrick87 (talk) 04:57, 14 July 2013 (UTC)
SVG guidelines
[edit]There is a discussion on SVG guidelines at Commons talk:SVG guidelines. JKadavoor Jee 17:06, 5 August 2013 (UTC)
Period before auto-archiving
[edit]I completely understand the rationale as to why the length of time between marking resolved and archiving was set to be so long at the time as a compromise solution. However, looking at the request page at the moment, 13 of the 28 requests are marked resolved, and most of these are only now about to be archived after sitting there for weeks. As I see it, it just makes the page look cluttered and people with requests probably assume that many requests simply aren't being tackled, which is far from the case as we all know. I think the page would look healthier with these requests getting archived faster.
Also, feel free to correct me if I am mistaken, but I haven't seen any request marked resolved in the past month that's needed to be marked unresolved or commented on, so there really doesn't seem to be any need to leave it so long. On enwiki, archiving usually occurred after a week (although the bot there seems to have shut down), and this system was perfectly adequate. There are so few cases that need reopening that I really think it's better for the page as a whole if we archived requests faster. Perhaps we could try 14 days and see how that goes before rushing into a week if it is still controversial. Of course if everyone else is happy with the current set up then we should keep it but I thought I should ask the question. NikNaks talk - gallery - wikipedia 22:40, 3 June 2014 (UTC)
LibreGraphics meeting 2015
[edit]FYI http://libregraphicsmeeting.org/2015/program/##kelvin-ma-creating-textbook-grade-svg-illustrations-for-wikipedia --Nemo 12:12, 12 May 2015 (UTC)
Please edit this page's header
[edit]Article(s): Illustration Workshop
Request:
Can someone more in tune with template markup please add:
{{notice|If you have completed work and not received a reply you may use the '''{{tl|GL Illustration reply}}''' template to inform the requester.}}
...to the page header so people know about the new template (blatantly copied from en!) for informing requesters that their request has been fulfilled --Fred the Oyster (talk) 19:52, 7 October 2014 (UTC)
Logo for Guianan Wikipedia
[edit]Hi, someone could help me and/or create the Guianan Wikipedia logo, because I don't really know what to do ?! LeGuyanaisPure (talk) 14:56, 1 March 2018 (UTC)
- I don't have the skills to help you with the logo. But to help other contributors, am I right to assume you're referring to this Wikipedia in the incubator? Where would the logo appear? Rupert Clayton (talk) 18:53, 1 March 2018 (UTC)
Edit a word !
[edit]HI, would there be someone who could replace the word "Ansiklopedi" by "Lansiklopedi" on these two images, please ? Thank you in advance ! LeGuyanaisPure (talk) 05:44, 3 October 2018 (UTC)
- please see: Commons:Graphic_Lab/Illustration_workshop — Johannes Kalliauer - Talk | Contributions 22:23, 6 October 2018 (UTC)
WikiProject COVID-19 Graphics
[edit]Hi all! We have been translating and setting up a graphics production line of the COVID-19 graphics at Meta:WikiProject_COVID-19_Graphics. The initial graphics have been The Spinoff animated gifs and another set which we have to withdraw. We currently have translations of these in nearly 50 languages, there are editable Photoshop files for each one them, shared online folders etc. Please join, and let's sync with what you do here! –Susanna Ånäs (Susannaanas) (talk) 06:47, 31 March 2020 (UTC)
Animated gif tuts
[edit]Do we have any? (For things like this) It would be nice to get involved, but difficult to do without a jumpstart :) hope everyone's well! Serial Number 54129 (talk) 15:18, 14 April 2020 (UTC)
Guidelines for requesting transparent backgrounds
[edit]After dealing with a particular logo recently, I have been unable to find a guideline to determine when an image should be listed in Images that should have transparent backgrounds and displayed with a transparent background or an opaque background (normally white). There seems to be a default mindset that all logos and illustrations (particularly SVGs) should have transparent backgrounds, regardless of:
- the impact of the change itself
- the visibility of the image when placed on a non-white background
- the construction of the image with regards to its creator's assumption of its usage
On the web, with the rise of "dark mode" and other accessibility tools, the flexibility of an image to be seen clearly in multiple contexts (backgrounds) is a worthy goal. Images like en:File:American_Osteopathic_Association_(logo).jpg assume placement on a light background. In order to be displayed on a dark background a light-colored holding shape must be used. I'd like to place some guidelines around this. My suggestion is:
- If an illustration has a clear and obvious border, the transparency should be up to the edge of the border. This applies to rectangles, circles, shields and other non-rectangular shapes.
- If an illustration has an evident framing shape that fully surrounds the image, then the transparency should be up to the edge of the assumed shape, and all additional background should be in white.
- If an illustration has no evident framing shape, then a simple rectangle of white should be put in place. The edges of the background will be equal to the furthest image element in the cardinal directions, plus an additional margin of 2% to 5%. When a rectangular background is in place, no additional transparency is required.
- If a different approach is warranted to maintain the design integrity or visual accessibility, it may be used.
Following these guidelines should provide Wikipedia with images that are usable in most contexts. --RossO (talk) 21:50, 16 November 2020 (UTC)
Translation
[edit]Is the Illustration workshop the right place to get a drawing translated to English? The text in the image is in German I believe. Jay (talk) 16:16, 13 May 2021 (UTC)
Vote for better SVG-Rendering
[edit]- meta:Community_Wishlist_Survey_2022/Multimedia_and_Commons/Improve_SVG_rendering till February,11th
- w:de:Wikipedia:Umfragen/Technische_Wünsche_2022_Themenschwerpunkte, till February, 6th (German)
— Johannes Kalliauer - Talk | Contributions 17:45, 31 January 2022 (UTC)
Illustrations from scanned books
[edit]Hi there, I'm trying to understand what's the current best practice for converting illustrations from scanned books for Wikisource. I'm able to convert them myself (e.g. File:Xilografia_canto_4.png from nap:s:Paggena:Viaggio_di_Parnaso_1666.djvu/40 but I'm not sure:
- If I should use png or svg for illustrations who can be represented in svg
- Which templates to use to indicate that's it's a derived illustration
- Which categories to use.
Can anyone help me? --Cryptex (talk) 11:59, 20 February 2022 (UTC)
- PS: I've just found [[Template::Extracted from]], looking forward to reading more tips. --Cryptex (talk) 12:13, 20 February 2022 (UTC)
- Uploading scanned images as PNG is completely reasonable. SVG files may contain PNG images, so any bitmap file may be an SVG file, but that practice is discouraged by many people. Glrx (talk) 18:16, 20 February 2022 (UTC)
- I meant converting some simple stamp-like illustrations from scanned bitmap to vector format. I can do that but I'm not sure whether I should. Cryptex (talk) 08:08, 21 February 2022 (UTC)
- @Cryptex: My view (not a standard practice) depends on the ultimate purpose. If the intent is to show designs from 1666, then I'd use a PNG bitmap. The bitmap could show the historical character of design such as printing defects and the age of the paper. If the intent is to use designs in new works, then an SVG could be better. The Xilografia canto 4 image has 9 repetitions of one shape (or 18 of a smaller shape), and SVG can handle that very effectively. However, just running a bitmap to vector converter on the image will not capture those repetitions, and vector applications often use straight lines where curves are more appropriate. It takes a lot of work to do a good vectorization, and it would be sad if the work is done but the vectorization is not used. For me, I would weight the effort against potential uses. Glrx (talk) 17:49, 21 February 2022 (UTC)
- I meant converting some simple stamp-like illustrations from scanned bitmap to vector format. I can do that but I'm not sure whether I should. Cryptex (talk) 08:08, 21 February 2022 (UTC)
- Uploading scanned images as PNG is completely reasonable. SVG files may contain PNG images, so any bitmap file may be an SVG file, but that practice is discouraged by many people. Glrx (talk) 18:16, 20 February 2022 (UTC)
How to create Multilingual SVG
[edit]Hi all, I've seen some SVGs that allows to choose the language (see here an example), but it's not clear to me how to create them. Is there any guide or tutorial? thanks! Sette-quattro (talk) 13:31, 3 May 2022 (UTC)
- @Sette-quattro:
- Multilingual files have several issues. A serious issue is whether a graphics editor can be used on the file after its conversion to multilingual. Inkscape can edit the file (but it can still wreck some translations), but editors such as Adobe Inkscape or CorelDraw may not be able to edit the files. If the file will need graphics editing, then it may not be a good idea to make it multilingual.
- The simplest approach creates an ordinary SVG that uses SVG
text
elements. Do not convert the text to curves. Then use the Commons:SVG Translate tool to add additional translations. The result will mostly work, but SVG Translate does not set up language defaulting correctly. - A more complicated approach is to make the SVG file with a text editor.
- For more information, see Commons:Translation possible/Learn more.
- Glrx (talk) 15:59, 3 May 2022 (UTC)
- @Glrx thank you! So would you recommend to use it or is better at the moment to upload multiple SVGs, one per language? I'm wondering which would be the best practice Sette-quattro (talk) 20:48, 3 May 2022 (UTC)
- @Sette-quattro:
- On Commons, I prefer multilingual files. It is easy for unskilled editors to add translations. Also, graphics updates are immediately available to all language versions. If there are separate files for each language, the graphics updates are usually applied to just one file; the other versions are not updated. A good example is File:2022 Russian invasion of Ukraine.svg. It started out as a monolingual English file that forked several language versions. The English version was updated frequently, and the translated versions were not updated. Then the original monolingual SVG was turned into a multilingual file. Many users contributed translations, and now the file includes 13 languages. The graphics are also being updated as the conflict progresses. That works because the translations are being added with SVG Translate, and the graphics are updated with Inkscape. (There are occasional problems that are fixed with a text editor.)
- Multilingual files, especially on Commons, do have significant issues, so sometimes separate SVG files are more convenient. The Commons rasterizer does not distinguish Chinese or Serbian script options. Timelines in LTR Western European languages are naturally left-to-right, but RTL Arabic and Hebrew want right-to-left timelines. A Latin language can rotate text 90°, but Chinese wants that text written top to bottom. Getting a multilingual file to work with many languages can be difficult. Also, a multilingual file can bloat; imagine the Ukrainian map's 600 place names translated into 50 languages.
- I wish Commons used the better method of using a skeleton graphics file that can have the translations merged into it. That would allow any graphics editor (not just Inkscape) to update the skeleton file without inadvertently deleting the translations.
- Glrx (talk) 22:14, 3 May 2022 (UTC)
- Hi @Glrx thank you for the detailed answer! due to my background I started contributing to commons mainly on maps and visualizations. I'm really interested in the systematisation of the SVGs usage on Commons, so if there is any way I can contribute to please let me know! Sette-quattro (talk) 08:50, 4 May 2022 (UTC)
- @Glrx thank you! So would you recommend to use it or is better at the moment to upload multiple SVGs, one per language? I'm wondering which would be the best practice Sette-quattro (talk) 20:48, 3 May 2022 (UTC)
FYI: It may help to see the following example of how multilingual files can be accomplished with minimal code:
<switch>
<text systemLanguage="ar">�����</text>
<text systemLanguage="de,nl">Hallo!</text>
<text systemLanguage="en">Hello!</text>
<text systemLanguage="en-au">G'day!</text>
<text systemLanguage="en-gb">Wotcha!</text>
<text systemLanguage="en-us">Howdy!</text>
<text systemLanguage="es">Hola!</text>
<text systemLanguage="fr">Bonjour !</text>
<text systemLanguage="ja">こんにちは</text>
<text systemLanguage="ldn">Wil sha!</text>
<text systemLanguage="ru">Привет!</text>
</switch>