Hey all.
As many of you already know, this summer I'm working on a project to enable SVG translation via a layer on top of the Translate extension.
This is my proposed translation page [1]. Imagine the "message definition" box in fact reads "Quantity of butter produced" and the thumbnail image displays "Lorem ipsum dolor amet" where "Quantity of butter produced" is displayed at the moment.
As you will notice, there is no space devoted to displaying qqq-message-documentation; I removed it on the grounds that it clutters the interface, for minimal benefit (you can see a thumbnail of the image which would include the message definition string, and I could have the image zoom when you click on it too, perhaps, in case it was a detailed map or whatever).
Nevertheless, I am not a translator, so I'm interested in what real translators think :)
Regards, Harry
-- Harry Burt GSoC student
[1] https://commons.wikimedia.org/wiki/File:TranslateSvg_preliminary_design_1.pn...
Harry Burt schrieb:
Hey all.
As many of you already know, this summer I'm working on a project to enable SVG translation via a layer on top of the Translate extension.
This is my proposed translation page [1]. Imagine the "message definition" box in fact reads "Quantity of butter produced" and the thumbnail image displays "Lorem ipsum dolor amet" where "Quantity of butter produced" is displayed at the moment.
As you will notice, there is no space devoted to displaying qqq-message-documentation; I removed it on the grounds that it clutters the interface, for minimal benefit (you can see a thumbnail of the image which would include the message definition string, and I could have the image zoom when you click on it too, perhaps, in case it was a detailed map or whatever).
Nevertheless, I am not a translator, so I'm interested in what real translators think :)
Hello Harry,
I don#t know if translation by SVG is really the right way. But as translator I say that a qqq-text (help text) for translation is indispensable. You must consider that there may be a lot of strings containing variables/parameters where a translator must know the context the string is used in.
Regards,
Michael
I thinking it may be important to have, and increase translation quality. Graphics and illustrations often contain abbreviations and such. It may be a Good Thing (tm) if those things can be annotated. The same goes for jargon, colloquialisms, and the likes.
-- Siebrand Mazeland
M: +31 6 50 69 1239 Skype: siebrand
Op 22 jun. 2012 om 15:23 heeft Harry Burt jarry1250@gmail.com het volgende geschreven:
Hey all.
As many of you already know, this summer I'm working on a project to enable SVG translation via a layer on top of the Translate extension.
This is my proposed translation page [1]. Imagine the "message definition" box in fact reads "Quantity of butter produced" and the thumbnail image displays "Lorem ipsum dolor amet" where "Quantity of butter produced" is displayed at the moment.
As you will notice, there is no space devoted to displaying qqq-message-documentation; I removed it on the grounds that it clutters the interface, for minimal benefit (you can see a thumbnail of the image which would include the message definition string, and I could have the image zoom when you click on it too, perhaps, in case it was a detailed map or whatever).
Nevertheless, I am not a translator, so I'm interested in what real translators think :)
Regards, Harry
-- Harry Burt GSoC student
[1] https://commons.wikimedia.org/wiki/File:TranslateSvg_preliminary_design_1.pn...
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Siebrand Mazeland, 22/06/2012 16:12:
I thinking it may be important to have, and increase translation quality. Graphics and illustrations often contain abbreviations and such. It may be a Good Thing (tm) if those things can be annotated. The same goes for jargon, colloquialisms, and the likes.
The question is whether such documentation should be in qqq or elsewhere: contrary to what Michael said, I don't think SVG text strings contain variables (please correct me if I'm wrong), so the text and context the translator sees is exactly what the reader of the image sees; if something is unclear, it should perhaps be explained in a legend to both the translators and the readers, not only in hidden documentation strings.
Nemo
Translating a SVG often does not require just translating the text itself, but also adapting its layout. Frequently, the labels have to be moved slightly. Legends will need to be a bit larger or will require that a single label takes two lines instead of one. The simplest labels like namse of cities or countries howver will not vary significantly in length, but abbreviations may be used sometimes. There are however some issues when labels are positioned in the SVG without using vertical and horizontal centering. Many maps are created for example that forget the alignment constraints that may be needed for translations. and they are packed so tightly that it is almost impossible to fit everything. A solution sing smaller font sizes may create something that looks random with labels of different sizes, as if the size was changing the relative importance of the label.
But the most problematic cases ocur when the color maps are badly chosen : small font sizes are hard to read when they are not contrasting enough. All labels should be only white or black. But the widest gammut of distinctive background is possible only with lighter backgrounds, so that most labels should be only black. The gammuts of background colors should also avoid some colors that are perceived with the same or very similar lightness, contrasting only in their hue, notably between some wellknown pairs which cause problems : green/red notably (and of course green/yellow in light shades, or marron/red in darker shades, as well as blue/cyan, cyan/green, blue/magenta and magenta/red in medium shades).
This is particular sensible if the colored areas to oppose have a small relative surface in the image, and even more important if you have used shadowing/lighting effects with non uniform colors.
In my opinion it is even better to have a non translated image that is accessible, than a non-accessible image that is perfectly translated but difficult to perceive and interpret due to poor color choices.
And most often, you don't need a lot of labels everywhere : they obscure the image itself. Sometimes just adding a small symbol will be enough (it shoudl be monochromatic and like letters of labels, should avoid oppositions of colors : you should better vary the symbol/icon size or the weight of its strokes)
2012/6/23 Federico Leva (Nemo) nemowiki@gmail.com:
Siebrand Mazeland, 22/06/2012 16:12:
I thinking it may be important to have, and increase translation quality. Graphics and illustrations often contain abbreviations and such. It may be a Good Thing (tm) if those things can be annotated. The same goes for jargon, colloquialisms, and the likes.
The question is whether such documentation should be in qqq or elsewhere: contrary to what Michael said, I don't think SVG text strings contain variables (please correct me if I'm wrong), so the text and context the translator sees is exactly what the reader of the image sees; if something is unclear, it should perhaps be explained in a legend to both the translators and the readers, not only in hidden documentation strings.
Nemo
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
On Sat, Jun 23, 2012 at 2:31 PM, Philippe Verdy verdy_p@wanadoo.fr wrote:
Translating a SVG often does not require just translating the text itself, but also adapting its layout. Frequently, the labels have to be moved slightly.
Hey Philippe. The current prototype (when it is finished) will allow for x/y-nudging, changing fonts and changing font-sizing (all of which you quite rightly mention).
But the most problematic cases ocur when the color maps are badly chosen : small font sizes are hard to read when they are not contrasting enough. All labels should be only white or black. But the widest gammut of distinctive background is possible only with lighter backgrounds, so that most labels should be only black.
I hadn't considered allowing the "translator" to recolour a label, but it's definitely something I'll look into.
Thanks, Harry
-- Harry Burt (User:Jarry1250) GSoC student
translators-l@lists.wikimedia.org