Hi,
Before I go to bugtracker, I'd like to make sure that this is a real issue.
Please take a look at www.lrn.ru/~avp/images/effects.png
The first thing is easy to see: there is no particular order in menu items, or, to be more precise, the order seems to be random :)
Would it be possible to at least alphabetically reorder menu items until extensions fraamework design (covering groups of effects etc.) is finished?
The second thing is that "Grid" appears translated in contrary to other effects. I have no idea how this has happened. Is it an issue to be addressed?
Best regards, Alexandre
The first thing is easy to see: there is no particular order in menu items, or, to be more precise, the order seems to be random :)
Would it be possible to at least alphabetically reorder menu items until extensions fraamework design (covering groups of effects etc.) is finished?
Weird thing is that on Win32 it does display alphabetically.
-Josh
Alexandre Prokoudine wrote:
The first thing is easy to see: there is no particular order in menu items, or, to be more precise, the order seems to be random :)
Would it be possible to at least alphabetically reorder menu items until extensions fraamework design (covering groups of effects etc.) is finished?
Well, there is no code in Inkscape to alphabetize them. I'm planning on doing that when I do the code to put them in submenus and group them. If someone would like to do that earlier, I have no problem with it, but I have no plans to do that independently.
That being said, I'm hoping to get the group functionality finished for 0.43...
The second thing is that "Grid" appears translated in contrary to other effects. I have no idea how this has happened. Is it an issue to be addressed?
Actually, all of the menu items are set up to look up the translation, I just haven't figured out how to get the entires into the .po files for the translators. "Grid" must be translated for something else in Inkscape, thus the translation gets picked up for the effect also. Theoretically, one could put all the Effect names in the .po files by hand and it would work, but we really need to figure out how to automate getting the entires out.[1]
--Ted
1 -- This really has to be the first step, eventually we need to be able to store translations in the .inx files themselves as they might come from other sources than the Inkscape codebase. But I have no idea how to do that at all...
Actually, all of the menu items are set up to look up the translation, I just haven't figured out how to get the entires into the .po files for the translators. "Grid" must be translated for something else in Inkscape, thus the translation gets picked up for the effect also. Theoretically, one could put all the Effect names in the .po files by hand and it would work, but we really need to figure out how to automate getting the entires out.[1]
--Ted1 -- This really has to be the first step, eventually we need to be able to store translations in the .inx files themselves as they might come from other sources than the Inkscape codebase. But I have no idea how to do that at all...
Hi Ted and all,
as a translator, let me comment on this : * I'd prefer not to split translation of extensions and core Inkscape string : - managing one file is easier than lots of them (and I hope the number of extensions will increase) - a lot of vocabulary is shared between core Inkscape and extensions * However, for some very short, or ambiguous strings, extensions developper should add a context prefix to the strings (it's what it's done for)
BTW : extensions are great and fun ! Thanks to Aaron, you and some others for this.
Regards,
Matiphas
On 7/30/05, matiphas@...8... <matiphas@...8...> wrote:
as a translator, let me comment on this :
- I'd prefer not to split translation of extensions and core Inkscape string :
- managing one file is easier than lots of them (and I hope the number of
extensions will increase) - a lot of vocabulary is shared between core Inkscape and extensions
- However, for some very short, or ambiguous strings, extensions developper
should add a context prefix to the strings (it's what it's done for)
How about translations in custom scripts or those that don't come with the Ink's distribution?
Alexandre
as a translator, let me comment on this :
- I'd prefer not to split translation of extensions and core Inkscape
string :
- managing one file is easier than lots of them (and I hope the numberof
extensions will increase) - a lot of vocabulary is shared between core Inkscape and extensions
- However, for some very short, or ambiguous strings, extensions developper
should add a context prefix to the strings (it's what it's done for)
How about translations in custom scripts or those that don't come with the Ink's distribution?
Well, I think that in this case, it's up to the developper to contact inkscape team. Everyone gets benefits from this : - developper can see its work validated, translated and benefits from the distribution capability of Inkscape. (plus some support for development, and of course credit for his work) - inkscape gets some additional tools/extensions/scripts - user gets more translated, verified features.
Regards,
Matiphas
On Sat, 2005-07-30 at 16:57 +0200, matiphas@...8... wrote:
How about translations in custom scripts or those that don't come with the Ink's distribution?
Well, I think that in this case, it's up to the developper to contact inkscape team. Everyone gets benefits from this :
- developper can see its work validated, translated and benefits from the
distribution capability of Inkscape. (plus some support for development, and of course credit for his work)
- inkscape gets some additional tools/extensions/scripts
- user gets more translated, verified features.
I'm not sure what the right answer here is, but I think we can assume that we'll have externally defined extensions in the future.
I was talking to a guy on Jabber last night who found a package for Novell 9.2 and was trying to install it, but it required pstoedit which he didn't have installed. I told him that he can --force it because Inkscape will detect and work around that omission from his system. There was no way for him to know that, and it may stop some people from successfully getting Inkscape installed. Stuck in dependency hell.
Likewise, people expect features which require all of these dependencies so things like .deb's "suggested" cause people to not have features they'd expect in Inkscape because they don't grab the additional packages (I don't think Synaptic even shows them).
I'm kinda leaning twoards the idea of: The Inkscape team will provide the best, most complete tarball in the world and packagers can weigh these issues for their various distributions. This way we can keep all the translations and testing together, while still allowing for flexibility all round.
Thoughts and ideas are always welcome.
--Ted
On Sat, 30 Jul 2005, Ted Gould wrote:
Date: Sat, 30 Jul 2005 14:30:55 -0700 From: Ted Gould <ted@...11...> To: matiphas@...8... Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net, Alexandre Prokoudine <alexandre.prokoudine@...400...> Subject: Re: [Inkscape-devel] effects menu
On Sat, 2005-07-30 at 16:57 +0200, matiphas@...8... wrote:
How about translations in custom scripts or those that don't come with the Ink's distribution?
Well, I think that in this case, it's up to the developper to contact inkscape team. Everyone gets benefits from this :
- developper can see its work validated, translated and benefits from the
distribution capability of Inkscape. (plus some support for development, and of course credit for his work)
- inkscape gets some additional tools/extensions/scripts
- user gets more translated, verified features.
I'm not sure what the right answer here is, but I think we can assume that we'll have externally defined extensions in the future.
Definately.
As I mentioned before I think a standardised plugin user interface should help alleviate the problem but it certainly will not solve it.
Likewise, people expect features which require all of these dependencies so things like .deb's "suggested" cause people to not have features they'd expect in Inkscape because they don't grab the additional packages (I don't think Synaptic even shows them).
I think some features have been somewhat over-sold. Users hear Inkscape supports Adobe Illustrator format but they rarely know it requires Sketch/Skencil (nor should they be expected to) and they usually dont realise it is a Unix only feature at the moment.
I'm kinda leaning towards the idea of: The Inkscape team will provide the best, most complete tarball in the world and packagers can weigh these issues for their various distributions.
If we dont provide the version that best shows off everything Inkscape can do who will? I see the downsides but I cannot help thinking most users want the features first and although they want the rest too the features win out.
On the other hand look at the trouble the gimp has maintaining the huge collection of plugins and extensions. All too often people developed extensions to scratch an itch but have little interesting in maintaining and improving them in the long run. Writing the software is nearly the easy part compared to maintaining it, translating it, making it accessible and keeping it consistent with the rest of the program.
The thing we can be optomistic about is that as Inkscape gets increasingly mature we can gradually depend on more and more of the platform libraries we want being preinstalled so at least that part of the packaging complexity will get easier. The level of support we want to provide to what is essentially third party functionality will continue to be a difficult problem to solve (but prehaps we could encourage some of them to turn the functionality we want into shared libraries). Who knows?!
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
On Sat, 30 Jul 2005, Alexandre Prokoudine wrote:
How about translations in custom scripts or those that don't come with the Ink's distribution?
The will have to follow standard interfaces and use pretranslations or else it is tough luck. With a good selection of pretranslated widgets and a standard template they will have little excuse not to.
I've seen extensions for Adobe products that use cheat and only graphics to avoid having strings to translate. Generally with compters it seems a lot of users are forced to learn enough English to get by so much so that we have users who prefer to use software in English rather thand put up with poor localisations.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
On Sat, 30 Jul 2005 matiphas@...8... wrote:
Date: Sat, 30 Jul 2005 11:07:35 +0200 From: matiphas@...8... To: Ted Gould <ted@...11...> Cc: Alexandre Prokoudine <alexandre.prokoudine@...400...>, Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] effects menu
Actually, all of the menu items are set up to look up the translation, I just haven't figured out how to get the entires into the .po files for the translators. "Grid" must be translated for something else in Inkscape, thus the translation gets picked up for the effect also. Theoretically, one could put all the Effect names in the .po files by hand and it would work, but we really need to figure out how to automate getting the entires out.[1]
--Ted1 -- This really has to be the first step, eventually we need to be able to store translations in the .inx files themselves as they might come from other sources than the Inkscape codebase. But I have no idea how to do that at all...
Hi Ted and all,
as a translator, let me comment on this :
- I'd prefer not to split translation of extensions and core Inkscape string :
- managing one file is easier than lots of them (and I hope the number of
If extensions are ever going to get translated it will be very important to make it as easy as possible for translators.
It will also help if there are standardised user interface widgets where possible (like Script-Fu from the GIMP only better). If there are standard widgets that can be used conveniently and are pretranslated there is a better chance of developers using them and extensions having a fairly consistent user interface as much as possible. (I've always liked how consistent the plugins are in Jasc Paint Shop Pro.)
extensions will increase) - a lot of vocabulary is shared between core Inkscape and extensions
the more the better, might be good to start creating a selection of INK_STOCK for buttons, menu items, and labels.
- However, for some very short, or ambiguous strings, extensions developper
should add a context prefix to the strings (it's what it's done for)
BTW : extensions are great and fun ! Thanks to Aaron, you and some others for this.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
participants (5)
-
unknown＠example.com -
Alan Horkan -
Alexandre Prokoudine -
Joshua A. Andler -
Ted Gould