Latest comment: 5 years ago27 comments6 people in discussion
Hello everyone! Our fantastic UX designer, PSaxena (WMF) made nice prototypes for you all to look at to get an idea of what the tool will look like. You can take a look at it using the links below which show some different images in the designs. Please note that it's a prototype and does not actually work. You will not be able to add translations to files or upload them to Commons. There are only a fixed number of files (linked below) that you can look at. Features that are in the prototype may or may not be present in the final tool - they are only meant to show the design. Your feedback would be welcome.
Pinging all the usual suspects - @Waldir, Strainu, Ruthven, Dvorapa, Glrx, and JoKalliauer:. Looking forward to hearing your feedback on the general design of the tool and any concerns (or appreciations!) you might have. I'll note again that everything you see here is only for design purposes and won't actually work. Also none of this is final and it can be changed based on feedback. Thank you so much. -- NKohli (WMF) (talk) 00:08, 10 November 2018 (UTC)Reply
Hi NKohli, great job! The interface looks simple and very intuitive to use.
Doing some tests, I've noticed a couple of possible improvements:
it is not possible to blank one word, when this can be useful in certain cases (e.g. a densely annotated map);
certain special characters are not read (e.g. &)
it could be useful to move the labels order (e.g. ATLANTIC/OCEAN -> OCEAN/ATLANTIC), because in certain language the order is different (e.g. Italian: Oceano/Atlantico). Of course "Oceano" can be written instead of ATLANTIC, if the semantic value of one label will never be considered.
Thanks for your comments, Ruthven! To the points you raised - you can blank a word by entering empty space. This is so people don't accidentally forget to enter translations. Does that seem like a good idea? About special characters not being read - it will work in the final tool, the prototype has bugs. :) About moving label order - that's an interesting idea and I will talk to the engineers about it. There are challenges on how we will be able to remember that information in the SVG file because there is no good way that SVG format allows us to store different label-ordering for different languages, unfortunately. -- NKohli (WMF) (talk) 21:35, 13 November 2018 (UTC)Reply
I have just 2 more things in addition to what Ruthven said:
The list of languages is huge, it would be great to have a hyerarhical list like we have on Wikipedia interwiki.
There seems to be no place for suggestions. I know this is a non-mvp feature, but changing the design a second time seems a bit useless.
@NKohli (WMF): I meant that having the image on the right of the translations leaves no place for the translation suggestions. Based on previous experiences in the Wikimedia world I would have expected the image to be on top of the strings (and stay there) and the strings to have an interface much like translatewiki, expanding and compressing as the user goes to the translation.--Strainu (talk) 23:28, 13 November 2018 (UTC)Reply
@Strainu: I see what you mean now. Thanks for clarifying. Keeping the strings on top of the image will work on desktop but probably not on mobile and we will run into issues with larger images. Good point about suggestions though. I will discuss that with the designer and see if we can make the design work better for suggestions (though suggestions are not a part of the MVP list of features, sorry). - NKohli (WMF) (talk) 23:51, 13 November 2018 (UTC)Reply
Wow, it looks really simple, but does the job really well. I've found only some minor and some major issues. Minor: First, the name of the Czech language contains a typo (čEština -> Čeština). Second, if I change a language, the dialog popup shows all my translations will be lost, but after clicking OK only the first translation is lost. Third, on the first load no buttons, texts, or input fields were shown, needed to reload. Major:
I love the interface (how the image is fixed position, but the page scrolls). I would just make the header narrower, because I don't like I have to scroll to the actual image so much. Just few pixels would probably do.
I still miss what I've already said, some upload button for translated files (from Commons). For multiple images there already are translated files uploaded to Commons with a title like "Original_image-pt.svg". It would be super useful just to upload the existing file and not work out or copy texts from the old file (if not translated to curves). The text usually is on the same place, just it has to be extracted (if possible) and merged to the original.
@Dvorapa: Thanks for the feedback! All of the minor points to you wrote will be fixed in the actual tool. They are bugs in the prototype which we are not working on fixing because it is only for design purposes. About the major points - good point about making the header narrower, I will convey that to the product designer. For the second part - I don't know if we will be able to get around to doing the merging anytime soon but it is still on my optimistic list of non-MVP features. I appreciate your feedback. -- NKohli (WMF) (talk) 21:35, 13 November 2018 (UTC)Reply
numbers are very much off (where does 4 and 5 belong, they are in the middle of two arrows)
I know thats Features, that might still have to be implemented, but you might can add them already now to the Grafical user Interface, maybe with the comment (feature under progress) and just link them later to their real function.
@JoKalliauer: Re-arranging text is not in the initial list of features so you cannot do that yet. See the non-MVP feature list. We are focusing on adding the basic functionality first. For choosing a language - you wouldn't necessarily have to. But if you are adding translations for Punjabi and want to use Hindi to compare with, it is easier than using only numbers. By default, you will get the Default option in the language dropdown so you don't have to pick. If the prototype doesn't do that, you can ignore it. It is only for demonstration purposes. Lastly, the tool will only create language-switch files. All translations will be added to the existing file and then uploaded to Commons. The tool will not create separate files for all translations. Thanks for your feedback. Much appreciated. -- NKohli (WMF) (talk) 21:52, 13 November 2018 (UTC)Reply
Comment.
I'm happy to see an SVG image rather than round-tripping the PNG conversion. SVG is an abstract language, and all SVG user agent should produce similar images.
I do not like the progress bar feature. I cannot save the file until everything is translated. In many situations, a label need not be translated. Consider the numbers for latitude and longitude on a map; they can be the same for de, en, es, it, .... In many technical illustrations, some terms may not have translations yet or the translator may not know how to translate the label. For example, maybe somebody can translate "guanidine" but not "transcription enzyme" or "transcriptase". The tool should allow partial translations, and for switch files, missing translations can be obvious. Allow incremental translations.
I'll second Strainu's complaint about the image being to the side rather than above. The image should also be sized so it does not scroll. For the map case, one of the translations is near the top on the left, but near the bottom of the image. If the list of translations were a little longer, one would have to scroll to the bottom of the text in order to see the bottom of the image.
Continuing Strainu's complaint. 50% of the screen area is devoted to several translation units, but the user will be working on only one translation unit at a time. Translation tools often have translations options. The left column may have the text to translate (e.g., "lighthouse"); underneath is translation. The right column may have several potential translations obtained from the translation database (e.g., "fanal" and "phare maritime"); the user could click one to select/replace as the translation.
If the whole translation unit were inserted into a textbox with newlines for the separate lines, then the line switching would be natural. Glrx (talk) 18:03, 19 November 2018 (UTC)Reply
Thanks for your comments, Glrx. Responding to them below -
The progress bar feature is unrelated to the fact that all translations are required. If you don't like the progress bar design, then that's a separate thing. :)
There are a few reasons why the software asks user to supply all translations right now - 1) What is the expected behavior when a user does not supply a translation for a string? Do we save it as blank in the SVG? Or do we not save a translation for the label? If we don't, what do we display to the user for that translation? Also, like you said, in some cases, labels should not be translated but there is no way for the software to be able to understand that. The easiest way to solve this is to allow the user to tell us. If the translation is same as the label, then the user can copy-paste the label into the translation box or add a blank space in the input box if they do not know the translation and don't want to translate yet. If it helps, we can add a checkbox to every label to allow users to say that the translation is same as the input label for numbers and medical terms which are not typically translated. What do you think?
We tested with several images and if we place the image above, it leads to a lot of screen-space wastage and the images are generally harder to read - especially ones with small text (like File:Plant_cell_cycle.svg). Putting it on the side and allowing it to scroll with inputs seems to be more efficient. I don't fully understand your point on why this is a problem - can you please explain more? The image will always be fully visible to the user and never cut-off on the screen.
About suggested translations - point noted. While we are not working on adding those right now but we will keep that in mind for the design.
The problem with whole translation units was discussed in this ticket - task T202771. The engineers could not come up with any decisions on how to handle that sort of line-breaking. For now we have to go with the simpler solution and I can surface the textbox solution to them once again after we have a basic tool up and running. Discussions like those seem to take a lot of time which is more usefully spent on engineering work. I believe you were subscribed to the ticket and followed along the discussion. -- NKohli (WMF) (talk) 19:26, 19 November 2018 (UTC)Reply
I do not like the progress bar. It suggests to the user that everything must be done now.
Got it. That's not the intention of the progress bar. It's only meant to indicate that there are empty inputs remaining. That said, I will take your feedback into consideration. Thank you. -- NKohli (WMF) (talk) 23:49, 19 November 2018 (UTC)Reply
Your alternatives here are confused. If no translation is given, then switch should select the default (e.g., numbers) or, alternatively, the default text could be (but not must be) copied (e.g., cognate). The absence of a specific language clause indicates it has not been translated or need not be translated. The presence of the a foreign language in a de clause suggests translation is needed. Neither alternative seems perplexing. Adding a blank space to the input box suggests the translation is blank space (i.e., not needed) rather than deferred. See also translate="no".
There are two cases, as you mentioned -
Case 1: The user has not added translation (because they didn't know how to or didn't have time etc)
In this case, we want to not copy the default text so the file knows that there is no translation for that label and next time that file is loaded in the tool, the user should get a blank input for the labels without translations. This way the file in that language will be rendered only using the translations, without the English/numbers text.
Case 2: The element does not need to be translated (like a number of scientific term)
In this case, we want to copy the default text so the file knows that the translation is the same as the original text i.e. translation is not necessary. So this way the file will be rendered with the English/numbers text along with the translations.
The tool does not know how to differentiate between these two cases so there is a need for the user to tell us whether the text should be copied or not. Right now, in the first version of the tool, to make this problem simple, we are always creating a copy of the text. If the user does not want to translate right now, they can add a blank space. On the other hand, if the element should not be translated, they can copy the default text in the input box and save it. This is only an interim solution while we figure out a better way to handle this situation. Does that make sense? -- NKohli (WMF) (talk) 23:49, 19 November 2018 (UTC)Reply
I do not understand. If text is difficult to read at full-screen width, wouldn't it be tougher to read at half width? You can make a landscape versus portrait argument, but there are images that are short and wide and vice versa. Load https://prtksxna.github.io/svgtranslate-prototype/map-simple.html and look at Mediterranean Sea. On my laptop full screen display (1366 x 768) under Chrome, if I put the text Mediterranean Sea at the top left, I only see the top 50% of "Mediterranean" in the image; if I scroll to see all of MS in the image, the left text only displays "Sea". If there were more labels to translate, I would have to scroll to the bottom of the left text list to see the bottom portion of the SVG. (top of SVG preferentially displayed until bottom of container is reached)
Ah, I udnerstand your point now. It is a bug that you are seeing. The image should scale down to fit the page width. That doesn't happen in the prototype. It will be fixed in the main tool. We will do some testing to see if we can implement the solution @Dvorapa: suggests below. Thanks Dvorapa. -- NKohli (WMF) (talk) 23:49, 19 November 2018 (UTC)Reply
I've already said I love the image to the side and in fixed position. But I have to agree with guys, that for some images, like File:Elements abundance-bars.svg, this design does not work. The tool should get the image proportions and adjust its layout for images like this. For wide images like this it would be cool to have the image below for even wider images it would be cool to have hozirontal scrollbar only for the image, for high images it would be coll to have separate vertical scrollbar too (or auto-scroll depending on the label currently translated? that should be easy to code as we already know the position of the text translated currently in the image, or not?). --Dvorapa (talk) 22:03, 19 November 2018 (UTC)Reply
Or maybe all images to the side, but the zoom adapted and separate scrollbars. I don't know, what solution would work. The main aim is the SVG file readability there. The file I posted would probably need only a half or less to be visible (the rest of it hidden under scrollbar) and slightly zoomed. But this needs to be investigated and brainstormed. --Dvorapa (talk) 07:27, 20 November 2018 (UTC)Reply
Glrx Hello. I want to flag something for you. We will be showing PNG images instead os SVGs in the tool. See the relevant task T211637. This is because we found out that SVGs in the tool won't necessarily render the same way as they do as PNGs in MediaWiki. So to keep the image preview be as close as possible to what is being actually rendered by MediaWiki, we had to switch to rendering PNGs using the same library as used by MediaWiki. I hope someday MediaWiki can be modified to render SVGs as SVGs so we don't have to resort to doing this. -- NKohli (WMF) (talk) 02:30, 15 December 2018 (UTC)Reply
@NKohli (WMF): I understand from where you come, but I dislike the idea of rendering PNGs instead of using SVG. librsvg has too many bugs, and it is a poor idea to pander to its foibles. Instead of investing in workarounds, fix stuff where it is broken. Some librsvg bugs have been fixed in the current release, but MediaWiki cannot use the current release. (And I know that browser SVG implementations also have bugs.) A more involved reason is programs that manipulate SVG want the SVG DOM, and you do not get that with a PNG. With the SVG DOM, one can easily use bounding boxes to compute string lengths and access the computed styles. Glrx (talk) 03:15, 15 December 2018 (UTC)Reply
@Glrx: I'm not entirely happy with the plan myself but fixing bugs in librsvg or adapting MediaWiki to upgrade to its latest version is well beyond our scope. It involves a lot more stakeholders and other teams and this project will be stuck in the weeds for a while if we go that way. We will not be manipulating SVGs directly and instead round-trip after every added translation to generate a preview. We could just go with SVG but doing that does not guarantee that what the user sees will match up with what it looks like once uploaded such as rendering fonts the user might not have on their system. I understand your concerns well and in an ideal world, we would not have to render PNGs. Doing PNG rendering is definitely more work for us and not the way we'd like to do it either but it seems like the most reasonable approach for now. -- NKohli (WMF) (talk) 04:04, 15 December 2018 (UTC)Reply
Will they work the same way as in the preview? Dynamically changing text in the image as user types? It was a cool feature in the preview and it should not be removed. --Dvorapa (talk) 08:51, 18 December 2018 (UTC)Reply
@Dvorapa: Yeah, it will work the same way. The text will update after every word/phrase has been translated and not after every character (as in the prototype). That is because updating after every character will be slow and create more load for the server. -- NKohli (WMF) (talk) 02:35, 3 January 2019 (UTC)Reply
Latest comment: 5 years ago29 comments7 people in discussion
Hello everyone! I have a good news. After our discussions in the past few weeks, we realized that serving SVGs in English by default is a big problem and spent some time working on it. We have been working on (task T205040) for the last few weeks and I am glad to say that we are close to launching it. The feature is available to test on the beta cluster. I have been testing it with this file which has a lot of switch translations. I tested it by embedding it on the German beta wikipedia (here) and Hebrew beta wikipedia (here). As you can see, in both cases the file renders in the wiki languages (German and Hebrew) without the need for a `lang` parameter in the syntax. We will be launching this soon on all wikis after we have tested it more thoroughly. I hope you all will take some time to test it too and tell me what you think of it. I will wait for feedback before we do a rollout to all projects. -- NKohli (WMF) (talk) 00:25, 1 November 2018 (UTC)Reply
Wonderful news. MW's librsvg has problems with hyphenated langtags (e.g., "en-US" and "zh-Hans"), but let's assume that will be fixed soon (Gnome claims the issue is resolved). MW does automatic script conversion for some wikis: e.g., Chinese (zh-Hans / zh-Hant) and Serbian (sr-Cyrl(sr-EC) / sr-Latn(sr-EL)). Does the script conversion also select the appropriate langtag for the SVGs? For example
@Glrx:, let's say it will be no more broken than it currently is for language variants specified explicitly via the lang parameter. There are definitely edge cases with variant handling that we may have to address later. Max Semenik (talk) 22:44, 8 November 2018 (UTC)Reply
The automatic language selection is a pretty nice and useful feature! Does it take the user's interface language into account, or does it only use the wiki's language? I think giving precedence to the user's language (if different from the wiki language) would be the ideal behavior, but others may disagree since images are part of the content, rather than the interface. --Waldir (talk) 19:46, 1 November 2018 (UTC)Reply
The current semantics are l10n to the wiki's language rather than i18n to the user's language. If MW starts serving SVG directly (rather than a PNG), then the l10n/i18n issue will need to be sorted out. If |lang= is present, it is an instruction to localize. The current change allows MW to avoid l10n instructions. Glrx (talk) 19:53, 1 November 2018 (UTC)Reply
Glrx is correct. While loading the image in the user's language can be useful, I don't think it's easy to do it with our current infrastructure. So for now this feature only shows the image in the wiki language. -- NKohli (WMF) (talk) 21:56, 1 November 2018 (UTC)Reply
Good news, I didn't know about the task. Please don't forget about alternative languages. If an SVG does not contain a translation for pt-br, don't forget to try to load pt-pt first before you finally load english. Exactly the same as MediaWiki messages work. The same e.g. for cs-CZ and sk-SK. Finally always thank you for mentioning us, I wouldn't notice anything otherwise. --Dvorapa (talk) 20:38, 1 November 2018 (UTC)Reply
Dvorapa Thank you for bringing this up. I believe currently we cannot do this. The image is always loaded in the wiki language and if it's not available, it is displayed in English. What you proposed will be quite useful. I will discuss this possibility with the engineers. Thanks for your feedback. -- NKohli (WMF) (talk) 21:56, 1 November 2018 (UTC)Reply
I see, hopefully there could be some hint for an implementation in the MediaWiki message system, but unlike MediaWiki, these alternative language choice mechanisms will need to be loaded live - this seems as a huge obstacle to overcome I understand. --Dvorapa (talk) 22:11, 1 November 2018 (UTC)Reply
@Dvorapa:. I do not know how the current system works or if anything special is done on the pt.WP, but the system should do something reasonable if any pt-* langtags are present in the SVG. I'll presume the pt.WP works just like the en.WP: the users of pt.WP may see either pt-PT or pt-BZ content: the pt.WP does not try to provide content tailored to a particular language variant. Consequently, the pt.WP should just ask whether the SVG file has systemLanguage attributes that are satisfied by the langtag pt? The answer is yes if the SVG uses the pt langtag or any pt-* langtag (such as pt-BZ, pt-PT, or even pt-CV). In other words, if an SVG file uses only pt-BZ (Portuguese/Brazil) langtags and no other Portuguese langtags, then the pt.WP should show the SVG's pt-BZ material. If not, then something is wrong. Similarly, if an SVG file's only English langtags are en-JM (English/Jamaica), the en.WP should display Jamaican English material even if the user is located in Great Britain (en-GB) or India (en-IN). Glrx (talk) 16:59, 3 November 2018 (UTC)Reply
Okay, but that is only part of the problem. What about cs-CZ and sk-SK? These two are almost the same languages, both nations understand each other in 100 % of cases, but they does not share the same langtag (cs x sk). --Dvorapa (talk) 17:12, 3 November 2018 (UTC)Reply
The code would have to follow a fallback list. That was contemplated, but I do not know if it happened. A workaround would be to make the SVG file have both cs-CZ and sk-SK translations/langtags. Glrx (talk) 21:22, 3 November 2018 (UTC)Reply
@Waldir, Strainu, Ruthven, Dvorapa, Glrx, and JoKalliauer: Hello again! I want to let you all know that this feature has now been launched to all wikis. If you now embed an SVG file on a wiki, it will show up in the wiki language if it's available else it will fall back to English. I know the fallback to English isn't prefereable but the way the system is designed, it is not feasible to add a fallback mechanism to it. I am sorry about that. However I hope this feature in itself will be helpful to many editors and readers. Please try it out and let me know if you see something not working correctly. Thank you all for your input. Much appreciated. -- NKohli (WMF) (talk) 23:41, 27 November 2018 (UTC)Reply
Awsome news, thanks! Unfortunately not many files are affected for small languages, so we do need your translation tool as well. When do you plan to make it widely available?--Strainu (talk) 09:48, 28 November 2018 (UTC)Reply
@Strainu: It's not ready yet. I believe we can have it ready for use by January. Because of the holiday season coming up and several people taking vacations, it's the best we can do. :) -- NKohli (WMF) (talk) 19:33, 29 November 2018 (UTC)Reply
where I expected the top image to be English as a legacy feature of the SVGImage page, but I was surprised that further down in the other versions section the SVG file (the image listing several languages in its caption) also displayed in English rather than German.
@Glrx: The work we did was to change the language for images rendered in article pages. You're right that it makes sense to also do this for File pages. I'll bring this to a meeting discussion to see if this is a small task we can easily do. If not, I'd prefer to first complete work on the tool before taking this on. Thanks for bringing this up! -- NKohli (WMF) (talk) 19:33, 29 November 2018 (UTC)Reply
@NKohli (WMF): Thanks. You did what I thought would be the hard case (display main image on SVGImage.php page) but not the easy case (which I would expect to fall out by enabling the feature for File pages). The other versions section invokes a template that includes a gallery; one picture in the gallery is File:Equatorial coordinates.svg (with no lang parameter). That file displays in English rather than German even though it is being viewed on the de.WP. I would expect the original fix, if enabled for File pages, would display in German.
I'm ecstatic with how the display in appropriate language feature is working out, so please thank your group. Images that were English can be augmented with translations, and those translations become visible on the appropriate wikis with no more effort. I can look at an SVG file page's transclusion list, see that it is included by several foreign language wiki's, and realize adding those languages would have immediate benefit. For example, File:Human leg bones labeled.svg is used on bs, id, mk, mr, ro, sh, and sr WPs. Sadly, I do not know how to translate femur, patella, tibia, and fibula into those languages, but when somebody does do the translations, those WPs will benefit. That suggests that WMF can have targeted challenges: please translate file X for language Y. Glrx (talk) 20:31, 12 February 2019 (UTC)Reply
If a file on Commons has switch translations, then the file description page with have a line near the top that says "render this image in" and followed by a drop down box that lists the languages. I'll agree that box is not very prominent. See, for example, File:First Ionization Energy.svg.
Both of these features existing in the current tool but it seems like they are not used as much. If these features do not seem useful, we can remove them and give the users a better experience. Looking to hear your thoughts on this. Thanks in advance. -- NKohli (WMF) (talk) 22:55, 12 October 2018 (UTC)Reply
Can you elaborate what exactly does "give the users a better experience" mean?
As long as there is a simpler path to get the images on commons, it makes sense that these features won't be used much by Wikimedians. However, they could be seen as a service from our community to 3rd parties, such as other wikis (wikia, private wikis) or even random users in need of an image translation tool. On the other hand, this upload-translate-download workflow should be kept separate from the commons-translate-commons one, as we don't want to end up with an easy way to "wash-up" non-free svgs (i.e. no upload-translate-commons)
I guess this is all a cost vs. opportunity decision that should be taken by the team. If implementing the features doesn't take too much engineering effort (say, based on absolutely nothing, one man-week for dev and maybe a couple of days for testing) they would be nice to have. If not, I doubt they will significantly affect the usage of the tool.
If they need to be prioritized, I would say the download is much more interesting than the upload, since some Wikimedians might try the tool, dislike it, then continue the translation offline (commons-translate-download workflow). If they can't download, they will loose their work.--Strainu (talk) 23:12, 12 October 2018 (UTC)Reply
I think similar, it is not really a technical question, it is more a political question:
If you let every image prozess, you are offering a tool for the WWW (then you need more server resources if it would become known)
If you only let commons.wikimedia.org and .wikipedia.org pictures prozess, then maybe educationlly useless pictures get uploaded, just to use the tool.
I think both are not very problematic, but if I have a SVG (f.e. created on my own, or downloaded from the WWW) and I want to make it multilangual I first have to upload it and then use the Tool and afterwards I would like to modyfy some thinks afterwards I have to create at least three files:
upload before the tool
created by the tool
modification after the tool (f.e. add comments before the switch-elements)
That might create a huge versionhistory (better for understanding the copyright-history, but bad for having a long list of useless files sored on the servers).
However images with `xlink:href` to external sources, should not be able to uploaded by the tool. (as by all other upload-tools, phab:T5537)
As said by Strainu it should be a decission of WMF-Team and the Developers-Team.
I am just afraid that the "Ability to import any image using the image URL" will become an open door for copyright violation. So, imho, no big deal in dropping the feature. To "Download the image with translations" should be maintained because we're talking about a translation tool, and because it would be helpful for third parties, as said above. Thanks for this feedback anyways! --Ruthven(msg)06:39, 13 October 2018 (UTC)Reply
Thanks everyone. What I meant by give users a better experience is that if we simplify the tool interface, it is easier to use for new people. What I am hearing is that it's okay to remove the Ability to import any image using the image URL feature because that can open a door for potential copyright violations but Download feature seems much more useful and should be maintained. If there are no objections, I would go ahead and modify the MVP. Thank you so much for your input. This was very helpful. -- NKohli (WMF) (talk) 17:33, 16 October 2018 (UTC)Reply
Recruiting for usability testing the prototypeedit
Latest comment: 5 years ago1 comment1 person in discussion
Hey o/ I am the designer for the SVG Translate tool, and I've been working on a prototype based on the wireframes and the feedback we've received for it. We'll be doing a round of usability testing using these prototypes and we'd would love to get your feedback on it.
We'll be using usertesting.com to get structured feedback and reactions on the prototype. We'll also be posting the prototype here for open feedback. If you're interested in participating in the usability test (it would be really helpful for us if you do), you can leave your email address using this form. We'll use it only to invite you to the usertesting.com test. --PSaxena (WMF) (talk) 08:18, 10 September 2018 (UTC)Reply
Latest comment: 5 years ago30 comments7 people in discussion
I've refined the Proposed solution section on the project page to identify which are the most important features that we will be working on adding in the first iteration of the tool. This lists the features that the tool should have and the gadget that should live on-wiki to make it easy for people to find this tool. I want to get feedback from everyone on what they think of this list as the requirements for the first version of this tool.
@Waldir, Strainu, Ruthven, and Dvorapa: I would like to hear what you think. Thank you. -- NKohli (WMF) (talk) 02:20, 23 August 2018 (UTC)Reply
The prioritization is clear from the document. However, the collaboration and login workflow are unclear to me. You mention the user can login with OAuth at any time to hold on to their translations, but they can only upload to commons after the user has finished translating all strings. This suggests that it will not be possible for another user to take over an unfinished translation. Can they at least restart the translation independently? How will races be handled? Also, what happens with the file if the user does not login at all?
@Strainu: My understanding is that showing the user half-completed translations is not a great idea because the user experience while seeing a half-English half-Russian labeled image is sub-optimal. In that case, it also leads to the SVG file and the tool itself being confused on what is already translated and what remains to be. Also most files seem to have a fairly low number of labels (less than 20) so completing a translation in one go should not be a problem. Do you think we should allows users to upload semi-complete translations? Another user can at any time reload existing translations and modify them.
The current tool (svgtranslate) supports the use case where a user can supply any file (does not have to be on Commons) and translate it and download it back. I don't have data to know how popular this use case is but it's easy to support it. So if a user does not login, they can still translate the file and download it for their purposes.
Good question about race condition. Here's my immediate thoughts: The tool may be able to show a popup on a corner when another user is modifying the same file. Flagging this for the project designer PSaxena (WMF). -- NKohli (WMF) (talk) 16:56, 23 August 2018 (UTC)Reply
We definitely don't want to show half-completed translations, I was referring to the fact that the wording suggested collaboration was not possible. It's good that someone else can load an existing translation. You might want to also consider translation reviews during the design phase (even if you don't plan to implement them). AFAIK major languages with many translators actively use this feature in tw.org.--Strainu (talk) 19:23, 23 August 2018 (UTC)Reply
The idea is that the tool does not hold translations but rather they are always on Commons. Having a review interface where people can see which files recently got translated in the language of their choice can certainly be handy. I will add this to the non-MVP list of features. Also I realized I did not answer your question about problem #7. We are going to do an investigation (phab:T202181) on that issue and see how technically challenging it is to include it to be a part of this project. I will update the proposed solution section on the project page based on the investigation results. Thank you. -- NKohli (WMF) (talk) 22:50, 23 August 2018 (UTC)Reply
(conflicted) Hi NKohli (WMF). Thank you for sythesising the most important features. To me they look all important (in tne MVP), but I see less important the following:
Allows a user to find a file on Commons: there is already a category and a template that, in theory, point to the translatable files.
Allows a user to download the file with the new translation: yes, but it isn't embedded in Commons already?
Then I've a couple of questions on the tool. Translations will be added to the same SVG file using switch syntax, fine, but how to select the language on the specific language on Wikipedia? We laso said that "Long translations do not fit": often I have to move the text labels to make a translation fit, and I think it's essential to have a readable map. Will this be possible with the tool or the file should be edited externally? In that case, wouldn't it be better to have separated files for each language version? --Ruthven(msg)06:32, 23 August 2018 (UTC)Reply
@Ruthven: The find feature will be an input box for the user to directly input a file name or URL. This is because the user may want to translate a file that is not on Commons yet. This is a feature the current tool (svgtranslate) supports and we want to continue supporting it to see if people find it useful. The same reason why Download feature is included.
To the question on how to select the specific language, Commons already offers a dropdown under the image called Render this image in which allows you to pick from the translations the file contains. See File:First_Ionization_Energy.svg for example.
For long translations, the MVP version of the tool will allow you to Preview a file to see what it looks like with the translations. They can use shorter words if the translation does not fit. In the next version of the tool, we want to allow for changing the positioning of the labels and modify the font size so the user can fit the translations better. Once that feature is included, do you think it is okay to have translations in the same file instead of creating separate language versions? A user can definitely create their own language version by downloading the file and uploading it themselves if they don't want to upload a new version of the existing file. -- NKohli (WMF) (talk) 18:26, 23 August 2018 (UTC)Reply
I think the MVP is sufficiently detailed and describes functionality that would satisfy the primary use cases for the tool. I could point out some minor details that could be clearer, such as disambiguating when you're referring to in-progress translation drafts under a user's tool-specific account, or finalized translations already present in Commons. Another minor point of confusion for me was what you meant with "and leads user to commons where they can input the description/file changes", as that didn't make clear how much guidance the user would have to regarding what such additional changes should be and how to perform them (this could be important for beginner users). But I'm sure more detailed mockups/storyboards will flesh out these details.
My main suggestion would be to, in the entry "Allows a user to preview the file", consider the option to have a near-instant, auto-updated preview, rather than a manually updated one. Perhaps this could be achieved by re-rendering only the text content of the file, atop a static raster rendering of the underlying image as a background. Such a double-layered approach sounds to me like it would enable live updates without much performance cost.
Good points Waldir. I am going to post some mocks soon and that should clarify some things. About the auto-preview, it is something that I will be talking to the engineers about. I totally agree that it will be useful to have that. I want the tool to get into a usable state as soon as possible so we can add nice-to-have features after the MVP is built. If it's fairly easy to do auto-previews compared to on-button-click previews, I would favor doing auto-previews. -- NKohli (WMF) (talk) 18:32, 23 August 2018 (UTC)Reply
I read the Proposed solution and User workflows sections and it seems almost ok to me. To the user workflows: There will be some images partially translated. Perhaps there should be some progress indicator/bar, how many % of the file is already translated for each file? This could be useful as a motivation to translate. To the last user workflow: We know there already are some files and their translated duplicates. I would imagine a part of the tool which:
allows to tick files in the same categories, that are dupes in a different language
allows to input a filenames of files, that are dupes in a different language
suggests some files the tool thinks could be dupes, but leave the decision to the user
after all dupes are successfully found and selected, it extracts the text from them and try to estimate the language (from filename, desc, extracted text), possibly ask the user to select one
matches extracted text to the fields
allows the user to check/fix/rematch extracted text
allows the user to exclude previously selected file (if the output of the tool is not correct or if the user doesn't dare to translate e.g. non-latin scripts)
allows the user to change dupes to redirs/mark dupes for deletion (?) after the newly translated SVG is saved
this should be allowed only if the SVG is 100 % translated to that language
this should be possible even if the dupe was previously excluded (the file can be dupe, but the tool can fail to extract the text from it/the file can be corrupted)
this should be possible also for PNG (etc.) files (sometimes the SVG file has a local variant in PNG format, the tool should help to merge them too even if it can not extract any text from them)
I also think this would be better not as a part of the tool directly, but as a separate gadget/tool/script in an post-MVP phase. --Dvorapa (talk) 15:23, 26 August 2018 (UTC)Reply
We are planning on adding an indicator for how many messages are untranslated. Like you said, it can serve as a good motivation factor. The outline you describe for the last user workflow is interesting. I agree that it should be an extension of this tool or a separate gadget/tool. -- NKohli (WMF) (talk) 22:49, 28 August 2018 (UTC)Reply
@NKohli (WMF): Thanks for pinging. I am following/reading every edit here since February, and subscribed phab:T201207 since 2Weeks. I am interested in a simple, cheap support, for "dumbest assumable user", such as ‘SVG Translate’, that new users do not have to ask the graphic-labs and are able to translate it on there own (I originally thought about only fixing the upload of phab:T164275). I prefer switch-Tags (TranslateSVG extension). Since Glrx (and others) have more knowledge and experience about it (see f.e. Grants:Project/Glrx/SVG_i18n (the luxury version)), I will only contribute if I can contribute something useful. As said before a simple solution would be enough for me, but I'm also happy about more sophisticated versions. — Johannes Kalliauer - Talk | Contributions15:22, 24 August 2018 (UTC)Reply
Haha. JoKalliauer, you heard Glrx! You're not to undersell yourself. :) I'm sure there are so many things we haven't thought of yet and someone with your experience will be able to guide us in the right direction. Please do chime in when you have something to add to these discussions and on Phabricator too. Even things like "that sounds fine" is very helpful in validating if what we're thinking/proposing is sensible from a user point of view. I appreciate it. Thanks. -- NKohli (WMF) (talk) 22:33, 24 August 2018 (UTC)Reply
@JoKalliauer: thanks for the detailed list! We are about to begin development on the MVP features for the tool and I will keep the project page up to date as we make progress on it. Thank you. -- NKohli (WMF) (talk) 22:20, 1 October 2018 (UTC)Reply
Readjusting the user interface page isn't a big deal; it can be done after many users comment. In many ways, it depends on user preferences. You might consider scrolling the source/target underneath the picture. That allows a larger picture and can keep the text being translated close to the picture. I might do source/target as two lines rather than side by side. Labels might be single words, but they also may be longer such as "low pass filter". If you are going to display possible translations, there needs to be a lot of space for them.
A server-side application can discover suitable translation languages from Accept-Languages. A client side application can discover the same information from the browser.
Each translation unit should have a check box to say do-not-translate. Those TUs can be hidden from the user unless she clicks show all TUs. The checkbox might be disabled and the TU grayed if the tools recognizes it is too complicated to translate (e.g., tspan with baseline shifts or font changes). The DNT can be stored in the SVG as its:translate="no" or translate="no".
Regarding the scrolling the source/target labels under the image - that is a good point. Same for language selection. We've been playing with ideas for what's the best way to handle that. I will talk with the project designer about this. About the do-not-translate tag - will this be on a per-language basis or for all languages? Can you give me a couple examples of when a user may not want to translate a label? -- NKohli (WMF) (talk) 22:38, 24 August 2018 (UTC)Reply
The its:translate="no" attribute applies to all languages and is inherited in the document tree. It says the text in this portion of the tree does not need to be translated (unless countermanded further down).
An illustration teaching the English language is an example. It might have an English phrase "Good morning" and offer the meaning in another text element that would be translated into de, fr, it, pt, .... The English would never be translated, but its meaning would be.
If an illustration quotes Caesar saying veni, vidi, vici in Latin, then the phrase would not be translated. The same illustration may have labels for Italy and Rubicon that might be translated. The SVG would have something like
<textits:translate:"no">veni,vidi,vici</text>
An illustration of the cipher in Poe's "The Gold Bug" would not be translated; neither would its 1-for-1 plaintext.
A diagram that showed letters on the 26 plug connections, 26 keyboard keys, and 26 output lamps of an Enigma machine would probably not be translated. That avoids 78 lines of translation, but still allows words such as "lamp", "keyboard", "plugboard" and "rotor" to be translated. Some labels are quotations about the machine, while other labels are descriptions appropriate for other languages.
For many languages, formulas such as F=ma or H2SO4 + Cu → H2 + CuSO4 do not need to be translated. The element symbols in chemical structure diagrams (e.g., N, H, S) probably do not need to be translated but other terms in the diagram such as "transcription", "DNA", "base pair", or "peptide synthesis" would be.
For the purposes here, I see it as a quick way to mark particular text as do not bother to translate.
Thanks for the detailed explanation Glrx. I have a couple thoughts on this:
What if a user comes in and marks a label as non-translatable but it's incorrect? Since it applies to all languages, we'd need to come up with a way to ensure that even if user A marks something as non-translatable by accident, user B can come in and be easily able to access those labels and fix the checkbox. There might be a conflict in where user A and user B don't agree on whether a label chunk is translatable or not.
The its:translate="no" attribute is not supported by SVG 1.1, correct? So for now the only use of this will be made by the tool, right? I wonder if it can throw off some image editors which don't understand what's going on. This needs more investigation.
Do you have an example image on Commons in mind that I can use to describe the intended behavior better with the rest of the team? I tried looking for one but didn't see any. -- NKohli (WMF) (talk) 23:05, 28 August 2018 (UTC)Reply
Think about how an ordinary user would use the tool to translate a diagram. The tool would extract all the text elements from the diagram and present them in a form for translation. The user would see "123", "veni, vidi, vici" or "H2SO4", realize they should not be translated, and click a checkbox that says do-not-translate. That text can now be hidden from view.
If the user wants to check all the text that has been marked do-not-translate, she can ask the tool to display ALL the text (along with their do-not-translate checkboxes). She can then uncheck the box. (There's a feature here, too. The do-not-translate check can be used to exploit switch default processing. Latin (*-Latn) languages do not need to translate quantities such as "14 kg", but Cyrillic (*-Cyrl) languages may want to use "14 кг" and Hebrew may want to use "14 ק"ג".)
its:translate is not supported by SVG in the same way that translate is not "supported" in SVG 2.0 even though it exists in the SVG 2.0 specification. The same is true of anything in SVG 1.0/1.1/2.0's metadata element such as the widely used RDF. The XML elements and attributes are there, but they have no influence on rendering the SVG. Both Adobe Illustrator and Inkscape add XML that is not in the SVG specification. User agents such as browsers and librsvg will routinely ignore the extra detail and paint the image. The issue as far as translation goes is whether such foreign extensions get stripped by graphic editors such as Inkscape, Adobe Illustration or Corel Draw. It's likely that only Inkscape will preserve the annotations -- but the other editors will probably toss the translations, too, so losing the its:translate attribute is a minor worry.
I don't know what you mean by an illustration showing intended behavior. File:Galvanic cell with no cation flow.png is a PNG, but it shows chemical formulas that need not be translated along with phrases such as "zinc anode", "copper cathode", "porous disk", and "anion flow".
Very nice mockups, thanks NKohli (WMF)! Besides what said above, we could also propose a default file name (like it's generally done on Commons for the translations). It should be Filename - lang.ext; where lang is the language code. Ex: Earth and moon - en.svg. Ruthven(msg)18:13, 30 August 2018 (UTC)Reply
Thanks for the feedback, Ruthven. Since we are planning to use switch-translations to add translations to the same file, suggesting file names would not be required as it uses the same file name. We're including automatic translation previews so users can see what the translated file would look like and adjust the labels, if needed. -- NKohli (WMF) (talk) 21:07, 30 August 2018 (UTC)Reply
Latest comment: 5 years ago32 comments7 people in discussion
Hello all. I'm Niharika and I'm working as the product manager for this project. I'm into the initial phase of my research and am digging into the user workflows around translating SVGs on Commons. Doing this will help us start creating rough designs which I will be sharing and gathering feedback. After several discussions, we have decided to build a new tool for this project which we will be maintaining. We are looking forward to collaborating with other developers who are interested in contributing to the project. If you'd like to get involved, you can join us in the discussions on phabricator (phab:T201207).
I have a few open questions that I am looking for answers for, wich will enable me to better understand the requirements of this project:
Thank you. -- NKohli (WMF) (talk) 22:37, 15 August 2018 (UTC)Reply
I have documented the two workflows I have discovered that exist on the project page. Are there any other workflows that I have missed listing? For example, do translators commonly want to find files they have translated in the past to add or edit translations? -- NKohli (WMF) (talk) 20:01, 16 August 2018 (UTC)Reply
I think the proposed workflow for the first use case ("This user would like to input the image URL in the tool to translate it or have the tool auto-complete the image name when they start typing.") is not sufficient. The tool should be amenable for integration via a link on the sidebar of File: namespace pages on Wikimedia wikis, so that one could simply click a "translate this image" link on the sidebar and be taken to the translation interface, with no typing necessary. For a user interested in an image in particular, I'd say this workflow would be even more convenient than having to visit the tool page and inputting the image name manually. Having both options would be great, but I'd prioritize the wiki-integrated one. --Waldir (talk) 08:19, 17 August 2018 (UTC)Reply
Thanks for pointing it out. That is an important point and I have clarified the workflow to indicate that. What I am aiming to capture in that section is how many different ways that tool can be used. -- NKohli (WMF) (talk) 17:09, 17 August 2018 (UTC)Reply
I believe there's a significant usage pattern that is missing from that list: maintenance-focused editors who may not be interested in particular languages, but would like to convert existing sets of translated images into a single image with a switch statement. I would place myself in this group. Is this something the tool could facilitate? --Waldir (talk) 08:22, 17 August 2018 (UTC)Reply
That's an interesting point. I can think of a few potential ideas, but I have no idea if they are technically feasible, so they're purely hypothetical until we talk to the engineers:
1. The user gives the tool the files they need to combine (maybe the tool automatically fetches the linked "Other versions" files).
2. For each file, the tool opens up the translations from all the files along with image thumbnails so the user can see which string belongs where.
3. The tool opens the SVG code for the file the user provided initially (in a side panel) and allows the user to add the switch statements. I'm not sure if the tool can automatically do this but I will pose that as a question to the engineers.
Does this sound like it'll be useful, Waldir? I also have a few questions for you -
* Do separate images get deleted once they are combined? What about the pages where those images were transcluded?
* How do editors currently find the images that need combining and how do they combine them?
* Can we safely assume that everyone wants to move towards single-file versions of images or are there still users who want to have separate files for translations?
I'm not sure whether the three options you mentioned were meant as mutually exclusive alternatives, or as potentially composable steps. Generally, the more automated and visual the workflow could be, the better.
As for your questions:
I think it should be safe to delete the multiple images as long as they're identical copies with only the text being different. Of course, expections may exist, but in such cases the community is capable of handling them. In any case, I don't think it needs to be within the scope of this tool to provide a way to delete the copies once they're merged. It would be a nice addition for convenience, but certainly as an extra, not a fundamental feature.
I'm not aware of any reusable workflow to locate such sets of images and do that sort of combining. Perhaps others will be more informed, but I don't think it's common practice, precisely because it's quite cumbersome to do manually.
I can't speak for the rest of the community -- as a WikiGnome, I tend to work mostly behind the scenes doing small, uncontroversial edits, and therefore don't coordinate much with other editors. From my POV, merging translated SVGs into a single image is a reasonable position, but others may have insightful comments that haven't occurred to me.
Thanks, Waldir. I intended the steps to be part of the same workflow. We will consider adding functionality for allowing users to do this type of maintenance, depending on technical feasibility and how quickly we can get the basic tool up and running. I have added this use case to the user workflows section. -- NKohli (WMF) (talk) 18:56, 20 August 2018 (UTC)Reply
Remerging split files should be a separate project; the tasks are different. I've added a lot {{Other versions}} templates to files to get a notion of what is going on, but it raises some thorny issues. An editor may upload a CC0 file, and then another editor may translate but upload the translation as a CC-BY-SA file. For the files to be remerged requires the new rights to be either respected or challenged. I would encourage the tool to require translation contributions be CC0.
A typical course is to leave old files around to preserve their edit histories. The files can be marked as superseded by other files.
It is not clear that single file versions are "safe". We should find out what happens to them in Inkscape, Illustrator, CorelDraw, and any other major graphics editors. @JoKalliauer: can probably tell us what happens with Inkscape. We don't want to turn files into objects that only wizards can edit.
It would be good to consider integration with existing tools such as CX or the VisualEditor. Also, the section does not state that it will be a ToolForge project, you need to go in other sections to find that out.--Strainu (talk) 22:04, 16 August 2018 (UTC)Reply
I was not sure if everyone would know what ToolForge is but I have updated the top of the project page to reflect that. We are planning on showing translation suggestions from TranslateWiki (see screenshot). I'm not sure if ContentTranslation offers APIs for integration but we'll check. Thanks! -- NKohli (WMF) (talk) 22:20, 16 August 2018 (UTC)Reply
That's an interesting idea. The reason it will be tricky to do is that the code has to figure out that the SVG file has text labels and is translatable. This is not natively handled by MediaWiki or CX and will have to be added to it, which is a great deal of work. The most straightforward way would be to link to the tool from the Commons image file page. This would work via a gadget (perhaps default) that lives on Commons and produces a link to the tool. The gadget can also potentially be used on other wikis to add direct translation links to SVG files so they don't have to go through Commons to access the tool. -- NKohli (WMF) (talk) 17:17, 17 August 2018 (UTC)Reply
I am not sure. It states some basic goals, but I don't get a good sense for computation or mechanism. Statements such as
tspan tag labels in a text tag are merged and presented to the user as one translation unit.
raise questions. tspan is used for line breaking, but it is also used for font changes, subscripts, and color changes. Just grabbing text.textContent can be the wrong thing.
I'm hearing ToolForge and gadget, but I'm not getting a notion of server and/or client processing.
@Glrx: good question. The proposed solution represents the basic functionality of the tool from a user's perspective. It does not yet say on a granular level how everything will function as the team is still working out the technical details. Specifically about line-breaking, I have a ticket (task T202771) for the engineers to compare different solutions and decide on the best way to implement this. As you know a lot more about how SVGs work than I do, your input on that ticket will be invaluable. -- NKohli (WMF) (talk) 21:43, 24 August 2018 (UTC)Reply
That's an interesting problem. Commons does have a feature to tell you if it finds a similar file when a user tries to upload a duplicate file. It should be possible to use the same code to allow users to discover same files with different names. I added this to the separate file versions problem section. -- NKohli (WMF) (talk) 22:26, 16 August 2018 (UTC)Reply
I believe the feature you refer to uses the SHA1 checksum of the image, in which case it's useless if the contents change (like they do for translations). I might be wrong though.--Strainu (talk) 11:26, 17 August 2018 (UTC)Reply
SVGTranslate relied on DerivativeFX to make a backpointer link on the Commons page. SVGTranslate did not enforce a convention that translating File:My Pretty Picture.svg to Klingon should upload the translated file to File:My Pretty Picture - tlh.svg. That would make it easier to find files. I look for similar names and all linked categories but still do not find all the descendants.
The backpointer should also have been added as CC RDF to the SVG's metadata. Yes, changing the content changes the SHA1 digest, but the
Sorry if some of those features allready whised somewhere else, or I added it at the wrong place (you can edit/delete/add point here, or move my edit), and some of them also are probably just "pie in the sky". — Johannes Kalliauer - Talk | Contributions21:01, 16 September 2018 (UTC)Reply
@Dvorapa and Ruthven: Adding a gadget on Commons (and other wikis) that links to the tool from the image page should work. For local templates, it could be a link that the community agrees to add. Do you think the links should only appear on SVG images in the Translation possible - SVG category or on all SVG files? How up to date is that category? -- NKohli (WMF) (talk) 03:23, 18 August 2018 (UTC)Reply
@NKohli (WMF): Well, the files that aren't tagged as translatable are difficult to discover. We will have for sure a lot of SVG files that can be translated but not marked as such. However, besides manually checking the uploads, there isn't much to do - unless automatically see if there is some embedded text in SVG files. --Ruthven(msg)21:46, 20 August 2018 (UTC)Reply
Image.php displays the "render this image in" dropdown box if the SVG has switch translations. A nearby button could offer to edit or add to the file's translations. Glrx (talk) 21:18, 24 August 2018 (UTC)Reply
Translate and wikilink through Wikidata: use QIDedit
Latest comment: 6 years ago3 comments3 people in discussion
For example File:Simple Periodic Table Chart-en.svg. It has the English words "group, period". Projected, is, add per chemical element cell their names (title) in en and wikilink to the en:wiki article. As we can see, the "en" qualifier is added to the filename (title). There is also derivate (code fork) File:Periodic Table Chart-sr.png, for srwiki (Serbian, in Cyrillic script BTW). Of course in SVG, we can add multiple languages in one file, and set the lang switch in respective wikis.
I'd suggest to add this option: add option QID's (for example, QID=Q925 for mercury, Mercury (element)). The cell "Hg" then has, for lang=en (!): title=mercury, link to = en:mercury (element) (note: the chemical symbols like "Hg" are not translated ever). -DePiep (talk) 10:11, 18 December 2017 (UTC)Reply
First, the indicated Chart has converted its text to paths, so it is a huge file (421 kB) rather than its initial small size (21 kB). The text should not use paths. We should encourage MW to directly serve small SVGs. (Switch translation works for a few strings in a few languages; for many strings in many languages, it can make the file large; in such situations, XSLT can be used to localize the file just as librsvg localizes SVG to PNG.) There should also be more space available for the "Group" string.
Second, I'd borrow the ITS / SVG 2.0 translate="no" attribute to mark most strings as "do not translate". That would leave only "group" and "period" for translation. (W3C validation will complain about the SVG 2.0 attribute.) There's no reason for tools such as SVG Translate to ask the user to translate "Hg" to "Hg"; tools should obey a do-not-translate instruction. (I'm not sure that is an absolute yet, but many languages would not translate them.)
Third, I'd mark the relevant strings with the attribute data-wd-q="QID". (W3C validation will complain.) "Group" would get group (Q83306) and "period" would get period (Q101843). The QID have names and aliases in dozens of languages that may be translations. Period in Korean is 주기율표 주기 . The elements would have their respective QIDs. (I'd also add the lanthanides and actinides.)
Fourth, linking won't work for the served PNG; the user would have to click through to the SVG. Instead of linking to the en.Wikipedia article, I'd link to either the Wikidata entry (the user can choose the wiki article) or go to an endpoint that will look at the user's ACCEPT-LANGUAGE request header[1] and redirect to the wiki article in the user's preferred language.
Hi. Which tool did you use? As I mentioned on the project and talk page, we don't have a tool currently. We only have a prototype only for illustration/design purposes. It is not supposed to work. -- NKohli (WMF) (talk) 21:10, 13 November 2018 (UTC)Reply
Latest comment: 5 years ago17 comments5 people in discussion
Hello @Waldir, Strainu, Ruthven, Dvorapa, Glrx, and JoKalliauer:. I just made a new status update on the project page. The tool is also available on the actual site but please be cautious when using it to add translations to files on Commons. We are still finding new bugs every day and sometimes they might end up corrupting the file on Commons. I am keeping a close eye on the files being uploaded to Commons using the tool to make sure we don't end up mangling any files. Feel free to test the tool though. Note that you will need to login before you add translations, if you want to upload the file to Commons. Thank you for all your patience and help with this process - especially Glrx. :)
I will keep updating the status on the project page as things move along. -- NKohli (WMF) (talk) 01:00, 15 February 2019 (UTC)Reply
Thanks for letting us know. There are 2 issues I saw right away: if the file is not recognized /found, I get a nasty internal error instead of a nice message. Also, I can't put in urls from Wikipedia. Strainu (talk) 07:25, 15 February 2019 (UTC)Reply
@Strainu: The first issue should be fixed soon but in the meantime, the search suggestions will be able to tell you which files exist on Commons. The tool is only meant to work with files on Commons now. We may or may not add support for other wikis in future. It's hard to say because this project has already lasted longer than we had hoped and we still have major bugs to address. -- NKohli (WMF) (talk) 19:48, 15 February 2019 (UTC)Reply
There is no reason to completely support local wikis (too many issues with badly marked copyvios), but you could check the url and if it matches a Wikimedia wiki you could check if the file is from Commons. If it is, great, if not, throw an error. I haven't checked the code to know if that totally easy or incredibly hard, just saying it could help speed up user process. Anyway, I suppose the code is open source, so perhaps we can log enhancements on that and someone might take them up.
But since you mentioned the duration of the project, what are the plans for maintenance? Will your team provide bug fixes? Will it review patches? Strainu (talk) 20:22, 15 February 2019 (UTC)Reply
@Strainu:, we are committed to keeping the tool maintained so it is in a working state, which was a problem with the previous tool. We'll try to do bug fixes and review code whenever we can. The code is indeed open source and we welcome patches. Also, a lot of problems you might see with files on the tool has to do with file code itself which can be fixed by fixing the file's SVG code. Glrx has been extremely helpful with that. -- NKohli (WMF) (talk) 00:21, 20 February 2019 (UTC)Reply
"has to do with file code itself which can be fixed by fixing the files's SVG code" is not an accurate statement. The tool fails on valid SVG that the tool should process or declare that it does not understand and refuse to translate. One can work around some of the tool's limitations by simplifying the SVG (such as removing redundant tspan elements, removing unintentional blank text nodes, and promoting style information), but few users have that ability. The tool targets users with translation skills rather than SVG or graphics skills. For most bugs, the SVG is valid, so work around edits should not be needed. The problem is the tool is not circumspect; it should examine a text element and decide whether it can process the element correctly rather than just forging ahead. I've been pointing out the SVG code that triggers a bug, can be used to find the offending code, and should be part of the tool's unit tests. I have only tried the tool on a few examples, and I have not examined its code. Glrx (talk) 20:46, 20 February 2019 (UTC)Reply
Can it be released as a Beta Feature? We're unsure whether there would be tech difficulties on using this tool, especially given at a very lengthy development. George Ho (talk) 01:04, 17 February 2019 (UTC)Reply
@George Ho:. This is an external tool so we cannot enable or disable it as a beta feature. Only changes in MediaWiki and extensions can be Beta Features. The tool has a banner on top saying that it is in early testing. -- NKohli (WMF) (talk) 00:16, 20 February 2019 (UTC)Reply
Umm... okay. Will the actual feature (not the external tool version itself) be released as Beta Feature or officially stable version (or something like that)? George Ho (talk) 07:43, 21 February 2019 (UTC)Reply
@George Ho: This project is for building an external tool, yes. The final tool is here - https://tools.wmflabs.org/svgtranslate/ but we should be cautious when using it. This is not part of MediaWiki and hence we cannot release it as a beta feature. Once the tool is more stable and there are fewer bugs, the team/community can work on a gadget or template to link to the tool from file pages on SVGs. That's a little far right now though. -- NKohli (WMF) (talk) 22:11, 21 February 2019 (UTC)Reply
@JoKalliauer: Thanks for testing. The problem with resizing the window is known but if you refresh in the resized window, you will be able to see the whole image. You are right about the problems with File:Anatomy_of_the_Human_Ear.svg. I will create tickets for them. It might be that the SVG itself is malformed which is causing the issues we are noticing. -- NKohli (WMF) (talk) 19:48, 15 February 2019 (UTC)Reply
The problem with "Malleus" in File:Anatomy_of_the_Human_Ear.svg was previously known. See Phab:T213937 and Phab:T215836. If a switch clause has an individual transform, then that transform replaces the switch element's transform, which moves all the switch element's text to the wrong place.
The missing words are in #text nodes rather than tspan elements. Apparently the tool gets confused when there is a mix. Opened Phab:T216282 → Phab:T216283.
The tool also is confused by formatting on tspan elements. See Phab:T215690. I do not think the tool's problem is with malformed SVG but rather the tool has trouble when the SVG does something beyond simple. The tool gets confused when there are both #text nodes and tspan elements or there are subscripts. See Phab:T216178. The now-removed File:999-percentages.svg was not malformed SVG; it just had extraneous whitespace that the tool should have been able to process. At this stage, it may be appropriate to limit the tool to processing vanilla text elements with a single #text node or a single tspan descendant.
A minor UI issue: I start the tool and begin typing a Commons filename. The tool prompts with a some possible filenames, and I click the one I want. The complete file name is now in the HTML input element, so I hit [Enter] and expect the tool to start working. After a sitting like an idiot for several seconds, I realize that nothing is happening and that I must click the translate button. Glrx (talk) 20:33, 15 February 2019 (UTC)Reply
@Glrx: Thanks for working all those issues out and writing Phab and comments, replied, suggested features,...
Argument 2 passed to App\OOUI\TranslationsFieldset::getField() must be of the type string, null given, called in /mnt/nfs/labstore-secondary-tools-project/svgtranslate/app/src/OOUI/TranslationsFieldset.php on line 31
Thanks JoKalliauer. We are slowly doing that. Right now since it's under active development, showing the exact error message helps us know what is going wrong exactly. We will eventually show a better error message for all errors. Thank you. -- NKohli (WMF) (talk) 23:35, 19 March 2019 (UTC)Reply
Latest comment: 3 years ago7 comments2 people in discussion
Hi,
I'm maintaining a small but complex SVG which shows a ever changing composition of a parliament seat allocation and is already supporting 13 languages. The recently contributed greek translation was done via SVG Translation and broke the already existing switch/group structure. Happy to modifiy the structure to support this tool, but I would need to understand what's needed on my side.--Aeroid (talk) 11:06, 21 June 2020 (UTC)Reply
@Aeroid: Your file contains more than 100 errors, some of them are severe, and lead to unpredictable rendering (e.g. symbol with transform). So your file is broken since the first version(15:03, 28. Aug. 2019).
Your SVG-file has an embedded <svg>...</svg>-tag in the mother-<svg>...</svg>-tag, that's imho an allowed feature, but neither common nor (in your case) usefull, that might confuse the translator and is so rar that I consider it as out of scope.
@JoKalliauer: indeed, quite embarassing to submit an invalid SVG ... thanks for pointing out and spending the time to try to clean up my mess. It should be clean an valid now.
Couldn't quite follow, why you changed id to data-name, as the validator also complained about those. I just moved them into comments, as they where just there to assit manual editing. Are they useful for the translation tool? If so, any idea how to use them and keep the SVG valid?
Again, thanks for the effort, I fell back to my version as I wanted to keep the rotate transformations and not use matrix.
Der Fehler ist liegt nicht bei dir, er liegt bei einer externen Software (librsvg), jedoch wurde dieser zwar 2018 gefixed, jedoch ist das Update bei Wikimedia nicht so leicht phab:T193352#4166886
Die Datei wird korrekt gerendert, also kann man den Error auch ignorieren.
Wenn den den Fehlermeldung beheben willst musst du transform="rotate( 190.00) translate(139,40 ) rotate(-190.00) translate(0,-2 )" in transform="rotate( 190.00) translate(139,40) rotate(-190.00) translate(0,-2)" ändern, oder am besten gleich in transform="translate(-129.94 -65.53)" (ist leichter zu lesen, schneller zu rendern und kummuliert keine numerischen Fehler auf).
Falls du das ausbesserst,kannst du auch gleich
die Schrift ausbessern: librsvg versteht DejaVuSansCondensed-Bold nicht und verwendet, stattdessen die Standardschriftart: DejaVu Sans, dies kannst du beheben in dem man font-family:'DejaVuSansCondensed-Bold', sans-serif; font-stretch: condensed; font-weight: bold zu font-family:DejaVu Sans, sans-serif; font-stretch: condensed; font-weight: bold ändert.
verschachtelte svg-tags sind unnötig kompliziert, in Zeile 306 ändere <svg x="0" y="0" width="900" height="500"> in <g> und dann auch in Zeile 681 </svg></svg> zu </g></svg>
Ich würde .rtext,.subhead,.head,.date,.legend{font-family:DejaVu Sans,sans-serif; font-stretch:condensed; font-weight:bold} herauslöschen und es stattdessen für das ganze SVG gleich in Zeile 3 in das <svg xmlns="http://www.w3.org/2000/svg" width="900" height="500" xmlns:xlink="http://www.w3.org/1999/xlink" font-family="DejaVu Sans,sans-serif" font-stretch="condensed" font-weight="bold"> hineingeben.
CSS führt häufig zu Problemen z.B. phab:T221382, daher entferne ich CSS üblicherweise wenn Probleme auftreten.
Schriftgrößen kleiner als 25px sollten aufgrund von phab:T36947 vermieden werden, bei deiner Datei passt es recht gut, aber File:Fonttest-Kerning.svg zeigt, dass kleine Schriftgrößen von librsvg 2.40.20 schlecht dargestellt werden Beispiel von phab:T36947.
Wenn du willst kann ich die oben genannten Änderungen übernehmen, ich wollte dich aber zuerst auf Commons:Commons:Commons_SVG_Checker hinweisen. (der generell viele Renderfehler findet)
Das einzige was für SVG-translate relevant sein könnte sind die verschachtelten SVG-tags.
<g transform="scale(1.33333333)"> hätte mir auch einfallen können, ich wollte es nur direkt mit <rect x="0" y="0" width="8" height="8"/> einbauen und als ich gesehen habe es funktioniert nicht, habe ich die schnellstmöglich meinen Fehler rückgängig gemacht. Zur Info: Die Version 09:58, 21. Jun. 2020 wurde von Google-Chrome es falsch angezeigt (wegen den <symbol transform="scale(1.33333333)">
Ich hab einen essay geschrieben, warum SVG validieren, nicht generell erwünscht ist.
zu data-name das ist ein SVG2.0-feature: [2], dass in SVG1.1 laut validator nicht valide ist, es hat aber weder in SVG1.1 (Da unbekannt) noch in SVG2.0 (da menschliches Kommentar/Bezeichnung) einen Effekt (daher ist das render-verhalten ident und somit ist mMn eher die Fehlermeldung eher als Feher zu interpretieren) und daher belassen werden sollte (man kann es auch in Kommentare schreiben.) Hingegen doppelte id-namen führen zu Problemen, wenn man auf diese mit xlink:href=" verwiesen wird, daher gibt es relevante und unrelevante Warnungen/Fehlermeldungen, xml-validatoren wie https://www.w3schools.com/xml/xml_validator.asp würden data-name auch nicht als Fehler melden, aber die finden idR auch nur klare Syntaxfehler.
Wenn ich Zeit finde, werde ich versuchen ein w:en:Minimal_working_example zu erstellen um den Fehler einzugrenzen.
Meines Wissen jedoch unterstützt svg translate keine Gruppen switch, also <switch><g systemlanguage=en>...</g></switch> wird nicht unterstützt, dazu müsste man die Gruppen auflösen zu <switch><text systemlanguage=en>...</text></switch>, das wird mühsam, also vermutlich ist die Datei out of scope des SVG-Translators. (Finde ich schade, weil ich auch oft so erstelle.)
@JoKalliauer: Noch mal Danke für die ganzen Hinweise ... dachte ich hätte schon viele Kniffe selbst gefunden, aber das ist ja die Hölle ;-)
die "Errors" zum Whitespace im Transform-Attribut ignorier ich mal, sehe keine Probleme.
Fonts hab ich korrigiert und werde ich bei meinen anderen Diagrammen auch bei Zeiten nachziehen.
Das Kerning sieht in deinem runterskalierten Beispiel übel aus, aber habe ich hier nicht als Problem nachvollziehen können. In Zukunft würde ich probieren einfach mit großen Canvas arbeiten und lasse es dann runterskalieren. Aber gut drauf zu achten.
Verschachteltes SVG, ja scheint hier überflüssig, aber war ein Workaround für falsche Justification (für nicht-linksbündige Texte). Schau ich noch mal genau drauf.
CSS habe ich auch noch nicht als Problem wahrgenommen, aber danke für den Tipp.
Ich verstehe, dass SVG-Translator vermutlich bei einem SystemLanguage-Switch auf Group-Ebene nicht die jeweils korrespondierenden Text findet, aber dann sollte er m.E. lieber die Arbeit verweigern, als das SVG zerschiessen. Oder?
Data-Name: Gibts da irgendeinen Nutzen den ich übersehe? Vielleicht etwas für das obige Problem? Aber wäre vermutlich nur ne Konvention.
du verwendest id zur Beschriftung, aber aus techn. Gründen darf eine id nicht doppelt vorkommen. "data-name" ist ebenfalls für die Beschriftung gedacht, hat aber im gegensatz zu id keine tech. Bedeutung und darf daher auch a)mehrere gleiche Beschriftungen haben (id nicht), b) mit einer Zahl beginnen (id nicht), c)Abstände, Beistriche, Hashtags enthalten (id glaub nicht) d.h. id hat tech. Bedeutung und kann probleme machen data-name ist als kommentar zu betrachten und hat keine tech. Relevanz. Du hast es jetzt mit Kommentaren gemacht das geht genauso.
Latest comment: 2 years ago1 comment1 person in discussion
Hi. It is [[:|File:Symptoms of influenza.svg]] and it improved in different languages. There are purely Ukrainian errors in the Ukrainian language file, which I replaced [3] and [4], this is reflected in File history of authentic file, but I can't replace the existing ones with my corrected ones. Someone can kindly give advice on how to do this? Sorry for my bad English. Thanks. --Шкурба Андрій Вікторович (talk) 00:35, 18 January 2022 (UTC)Reply
@Liglioto: I'm not quite sure what's happened. It looks like the new strings have been written into that file okay, but you're right, it's not rendering them at all. This might be phab:T270999 (the SVG is 426K). It doesn't seem to be finding the available lang list, but even adding lang=bg to the URL it doesn't work. SamWilson10:30, 26 May 2022 (UTC)Reply
.svg){kind=link}
![[3]](https://svgtranslate.toolforge.org/File:Symptoms_of_influenza.svg){kind=link}
![[4]](https://upload.wikimedia.org/wikipedia/commons/9/9e/Symptoms_of_influenza.svg){kind=link}
