UI Internationalization

[GoogleCodeExporter]

Instead of English words like "fill" "stroke" etc. that take up usable
space and are intended only for English-speaking people, would be better to
use small icons that are already consecrated for these concepts (from
editors like inkscape and the kind)

Original issue reported on code.google.com by Christia...@gmail.com on 8 Jul 2009 at 8:47

[GoogleCodeExporter]

I'm open to suggestions, please attach suggested graphics to this issue if you 
get
around to creating them.

Original comment by codedr...@gmail.com on 8 Jul 2009 at 10:14

[GoogleCodeExporter]

I spent the entire night creating these svgs, but i know they are not what you 
need
because they are too long.. anyway.. i just felt like i should make the effort 
that
you asked for

Original comment by Christia...@gmail.com on 9 Jul 2009 at 2:46

Attachments:

• svg-editor-images-svg.zip

[GoogleCodeExporter]

Wow - you actually created all these images from scratch in one night?!?  That's
amazing! :)  

I could see a lot of these being used for parts of the UI, we'll have to spend 
some
time in 2.3 planning this (2.2 is almost complete now).  I'm very happy with a 
lot of
these images (though I don't see an image for stroke).

Since you seem to have some artistic talent, would you also consider thinking 
of a
nice logo for SVG-edit?  See Issue 44.

Original comment by codedr...@gmail.com on 9 Jul 2009 at 4:16

[GoogleCodeExporter]

no, i haven't created them from scratch. only a small part. the rest are
modifications. but.. beware! they are very complex and upon inclusion as SVG 
they
will take too many CPU resources in the browser! they have to be simplified or 
have
2-3 sets of PNGs harvested at different sizes for each, and use the PNGs. 
about logo: i was thinking about it since yesterday. still no idea..
for stroke we can use the image of a pencil and for fill the one of a brush. 
both
only the tip of each tool (cause i had sent them, but not in this final form).. 
maybe
i should attach..

Original comment by Christia...@gmail.com on 9 Jul 2009 at 7:45

Attachments:

• stroke.svg
• fill-obj.svg

[GoogleCodeExporter]

Christian,

Yes, all the SVG files would be converted to rasters (PNGs) before including as
graphics in the editor.  Specifically because we use HTML for most of the editor
interface and Firefox doesn't support background-image or <img> for SVGs and 
for the
fact that we don't need to scale the images.

As for the images themselves, if you did not create them from scratch, can you
clarify where they came from - I want to be careful about copyrights.  
OpenClipArt?

Original comment by codedr...@gmail.com on 9 Jul 2009 at 2:38

[GoogleCodeExporter]

i used only sources with licenses compatible with GPL. ex:
http://commons.wikimedia.org/wiki/Category:Nuvola_SVG_filesystems
for those not created from scratch

Original comment by Christia...@gmail.com on 9 Jul 2009 at 3:04

[GoogleCodeExporter]

Hi Christian,

I sent an email to the svg-edit mailing group (and hopefully to you).

Regards,
Jeff

Original comment by codedr...@gmail.com on 13 Jul 2009 at 2:02

[GoogleCodeExporter]

With Narendra's UI internationalization changes, I think we can close this 
issue -
what do you think?

Original comment by codedr...@gmail.com on 4 Oct 2009 at 10:58

• Changed state: NeedsInfo
• Added labels: NeededFor-2.4

[GoogleCodeExporter]

Will there be a way to change/select language from inside the UI? - just a 
question!

Original comment by worms_...@yahoo.com on 4 Oct 2009 at 11:27

[GoogleCodeExporter]

Yes, I want to do this.  We just need a good way to achieve it without 
cluttering the
UI.  Suggestions?

Original comment by codedr...@gmail.com on 5 Oct 2009 at 5:03

[GoogleCodeExporter]

I think this is nothing for UI. I found this snippet:

  var l_lang;
  if (navigator.userLanguage) // Explorer
    l_lang = navigator.userLanguage;
  else if (navigator.language) // FF, Opera, ...
    l_lang = navigator.language;
  else
    l_lang = "en";

and it seems to be working. (But e.g. Firefox returns en-US for my system, so 
we 
have to check also en locale if en-US is missing - that's how glibc works 
AFAIK). If 
there are no objections I'll replace the get_lang_from_url_param with this 
detection 
+ some extra code. What do you think?

Original comment by rusn...@gmail.com on 5 Oct 2009 at 9:51

[GoogleCodeExporter]

There are still some messages/words which aren't translated in the chosen 
language:

- The word "Layer " which appears by default in the Layers table, and the 
subsequent
"Layer 2"

- The JavaScript messages when doing some actions: 
  - New Image / erase history dialog
  - Creating a new layer dialog
  - Renaming a layer dialog 
  - maybe others?

- The colorpicker Tab titles, descriptions and OK/Cancel buttons (this might be 
a
jGraduate issue?)

Would it be possible to get these things translated as well?

N.B.: I think we can keep "Powered by..." as such, because it's hard to 
translate,
and after all, SVG-edit is in English, at the beginning :p

Original comment by worms_...@yahoo.com on 6 Oct 2009 at 10:39

[GoogleCodeExporter]

Thanks for clarifying - yes, at least those 5 things you mention, plus we would 
need
to look at jGraduate/jPicker to see if it can be localized

Original comment by codedr...@gmail.com on 6 Oct 2009 at 1:55

• Changed state: Accepted

[GoogleCodeExporter]

> Comment 11  by rusnakp, Yesterday (31 hours ago)
>I'll replace the get_lang_from_url_param with this detection 
>+ some extra code. What do you think?
>
language detection is a good idea. In India there are more then 30+ well known
language but Everybody use English GUI based Firefox. How you can automate this 
?

Original comment by narendra.sisodiya on 6 Oct 2009 at 5:21

[GoogleCodeExporter]

I think what I'd like to see is:

  * Finalize localization of a few remaining bits (the "Layer " prefix for the
defautl layer name, the prompt strings)
  * Use prusnak's code to detect the default system language
  * Rename 'Doc Properties' to just 'Properties'
  * Make two tabs/sections in the Properties dialog - one for the document and one
for SVG-edit
  * Provide a pull-down option thing in the SVG-edit section of the Properties dialog
to let the user manually select the language
  * look at HTML5 local storage to see if we can save this preference: 
http://dev.w3.org/html5/webstorage/

I think localizing jGraduate/jPicker will be tougher since it's a 
general-purpose
thing and not specific to SVG-edit, so I'd like to save that to a later release.

What does everyone think?

Original comment by codedr...@gmail.com on 8 Oct 2009 at 3:52

[GoogleCodeExporter]

Great! I agree with all points ...

Original comment by rusn...@gmail.com on 8 Oct 2009 at 4:12

[GoogleCodeExporter]

a patch to the Ro file

Original comment by Christia...@gmail.com on 4 Nov 2009 at 9:14

Attachments:

• lang.ro.js.1.patch

[GoogleCodeExporter]

r928 (in transformlist build) adds many fixes, including support for the JS 
strings, 
rusnakp's browser language check (replaces URL lang option) and the ability to 
change language from the dropdown menu under doc properties.

Still to do is storing the language set, we could use webstorage where 
available, 
and good ol' cookies where not.

Also for those making translations, see the bottom of the lang.en.js file on 
the 
format for JS strings.

Original comment by adeve...@gmail.com on 10 Nov 2009 at 9:35

[GoogleCodeExporter]

Could we avoid cookies as much as possible? (I *hate* this variety of cookies).

Otherwise, nice!

Original comment by worms_...@yahoo.com on 10 Nov 2009 at 9:39

[GoogleCodeExporter]

I believe right now cookies are the only client-side method of having browsers
remember your settings...what is it that you hate about them? All we'd use them 
for
is to remember the SVG-Edit preferences so when you reload the page it'll go 
back to
using the same language that was set before.

Currently Opera is the only browser that doesn't support webstorage, and
Webkit/Chrome only support it in their latest versions. However, the Opera 
widget
does have the ability to do something very similar.

Original comment by adeve...@gmail.com on 10 Nov 2009 at 11:45

[GoogleCodeExporter]

As of r930 the language is now saved, so I'm going to close this issue.

We do still need to update the language files, but that can be a separate issue 
and 
only needs to be done when we're ready with everything else.

Original comment by adeve...@gmail.com on 11 Nov 2009 at 6:18

• Changed state: Fixed