Am Mon, 2001-10-08 um 22.47 schrieb 1002574041:
> I really think we should use XML for the tips but Marc is probably right
> that it only makes sense if we use it for other files too. If we decide
> to tackle some of our plug-in problems with XML, we will probably want a
> real XML parser. Tha
Am Mon, 2001-10-08 um 17.46 schrieb 1002555985:
> Which GNOME components does GIMP use?
None, that's the point. :)
--
Servus,
Daniel
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-develo
Hi,
<[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> writes:
> On Mon, Oct 08, 2001 at 06:53:24PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> > As Sven already mentioned, the solution would consist of adding a new
>
> I would also agree that the header idea is best, HOWEVER, Sven
> surprising
On Mon, Oct 08, 2001 at 06:53:24PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> As Sven already mentioned, the solution would consist of adding a new
I would also agree that the header idea is best, HOWEVER, Sven
surprisingly offered that it would be 10 minutes or so to use xml (he
seemed a
On Mon, 08 Oct 2001, Sven Neumann wrote:
> Daniel could you please take the discussion about UTF-8 and editors
> somewhere else?! Then, if you want to propose something that is GIMP
> related, please take your time to write up an elaborate proposal and
> try to explain your ideas in a way that al
For what it's worth, here is my opinion on the Tip of the Day messages
and their translations. In summary: keep it simple! I know that
being the one who introduced these tips in the Gimp does not grant me
any special priviledges (especially since I am not translating them)
but it looks like the
Hi,
Daniel could you please take the discussion about UTF-8 and editors
somewhere else?! Then, if you want to propose something that is GIMP
related, please take your time to write up an elaborate proposal and
try to explain your ideas in a way that allows us to discuss them
in a constructive man
Am Mon, 2001-10-08 um 03.53 schrieb 1002506022:
> > gettext and po
> > files are a dead end for modular applications because they only behave
> > well for monolithic and small applications; both of which GIMP
> > definitely isn't and for sure even less will be in the future.
> Evolution certain
Am Mon, 2001-10-08 um 03.39 schrieb 1002505193:
> > You don't have to, that's the trick.
> Ok, I got the impression from your message that this was the case.
The trick about it is that there's nothing special, so you can use
any editor you like, like with ascii files just the XML represents
info
"pcg"@goof.com ( Marc) (A.) (Lehmann ) wrote:
> > My mailer doesn't (pine)
>
> pine doesn't even parse rfc822 addresses (like mine) - let's face it, pine
> is the worst mailer around with regards to features, standards compliance
> etc. Everybody is free to use it, but citing pine as an example o
On Mon, Oct 08, 2001 at 05:00:27AM +0200, Christian Rose <[EMAIL PROTECTED]> wrote:
> My mailer doesn't (pine)
pine doesn't even parse rfc822 addresses (like mine) - let's face it, pine
is the worst mailer around with regards to features, standards compliance
etc. Everybody is free to use it, but
Daniel Egger wrote:
> > Yes, but that's the very nature of the ChangeLog. It is *supposed* to be
> > edited with every commit.
>
> Why does that make a difference?
> Rather the fact that every entry has to be added at the top of the file
> to keep the chronological order makes it much more confli
"pcg"@goof.com ( Marc) (A.) (Lehmann ) wrote:
> > Native support for UTF-8 is uncommon and of course that is bad and
>
> Sorry? my mailer supports it (mutt) my editor supports it (vim), my terminal
> supports it (xterm), my irc-client supports it (epic), my browser(s) suipport
> it (lynx, netscap
On Mon, Oct 08, 2001 at 03:39:53AM +0200, Christian Rose <[EMAIL PROTECTED]> wrote:
> Native support for UTF-8 is uncommon and of course that is bad and
Sorry? my mailer supports it (mutt) my editor supports it (vim), my terminal
supports it (xterm), my irc-client supports it (epic), my browser(s
Daniel Egger wrote:
> > I think you need to
> > consider the experience that menthos has with this situation. If we
> > consider what we might end up with in the future (many more tips, more
> > complicated tips, more languages), it makes sense to plan po right now.
>
> I'm never planning for no
Daniel Egger wrote:
> > Why should I have to use a special XML editor?
>
> You don't have to, that's the trick.
Ok, I got the impression from your message that this was the case.
> > How does the editor know what language I want to edit,
>
> Easy, you tell it.
So this is an extra step that I
Am Son, 2001-10-07 um 20.16 schrieb 1002478606:
> Yes, but that's the very nature of the ChangeLog. It is *supposed* to be
> edited with every commit.
Why does that make a difference?
Rather the fact that every entry has to be added at the top of the file
to keep the chronological order makes it
Am Son, 2001-10-07 um 19.34 schrieb 1002476057:
> Prof: Seriously here... are you a translator?
It's not my job. Though you can imagine that I have some experience in
this area as I'm the one who introduced localisation to the GIMP and
wrote a big part of the first translation for it. I did this
Am Son, 2001-10-07 um 18.43 schrieb 1002473012:
> Then you should take a new look. It certainly does today.
Fine with me.
> Why should I have to use a special XML editor?
You don't have to, that's the trick.
> How does the editor know what language I want to edit,
Easy, you tell it.
> and
Am Son, 2001-10-07 um 18.29 schrieb 1002472199:
> > Yes, but not very versatile...
> Why? It contains the tips and a minimum amoutn of clutter. If you equate
> evrsatile == xml because everybody claims to support it I disagree
> completely.
No, but unlike compiled catalog files xml files can b
Daniel Egger wrote:
> > Whatever the solution regarding GIMP tips turns out to be, translators
> > want to be able to translate them from within po files. I hope everyone
> > has agreed on that :)
>
> not really.
Okay, but that really makes you an exception among translators. This
discussion isn
Daniel Egger wrote:
> > Also, one important drawback of keeping all translations in one file in
> > CVS, and forcing translators to edit this file, is that it gets almost
> > impossible to verify the integrity of translations. As a translator and
> > creator and maintainer of the translation, I fe
I think that regardless of what the original format is, translators
should be given and work with po files. Christian Rose is right in his
reasons. I have a few more to add.
1) The translator can't accidentally edit the wrong place and mess up.
2) It is what translators are used to working with
Sven ...
[EMAIL PROTECTED] (2001-10-07 at 1656.37 +0200):
>
> hmm, wouldn't it be nicer to use the following instead ?
>
>
>
>
> This is the first trip.
>
>
> This is the second trip and it has bold text.
>
>
> This is the last trip. Now, you are o
Daniel Egger wrote:
> > Dia uses intltool/xml-i18n-tools for sheet files.
>
> That's new then. They didn't when I was translating the sheets.
Then you should take a new look. It certainly does today.
> > Because one of the fundamentals of easy translation is simply to have
> > the original tex
On Sun, Oct 07, 2001 at 03:30:06PM +0200, Daniel Egger <[EMAIL PROTECTED]> wrote:
> > our parser isn't homebrewn and is much better supported by glib than XML
> > is. s-expressions are in my opinion easier to read and write for humans
>
> Knowing that you're an EMACS user I definitely think this
On Sun, Oct 07, 2001 at 02:46:35PM +0200, Daniel Egger <[EMAIL PROTECTED]> wrote:
> > really???
> I've heard there are Perl hacks as well. :)
There are hacks for a lot of other languages/environments ;) The
shortcoming of gettetx lies not int he parsing and input format...
> > which would be eas
Daniel Egger wrote:
> > I'm not not exagerating. A typical tip consists of multiple lines (2 to 5)
> > and you can't translate them line by line. My typical emacs setup shows
> > about 42 lines, while the typical distance between the original tip and the
> > translation will be around 40 to 100 li
Am Son, 2001-10-07 um 17.25 schrieb 1002468356:
> XML schema has only become a W3C recommendation lately and is
> probably far from being finally standardized. AFAIK there are only
> few (if any at all) usable tools out there that can validate XML
> schema. I think you meant to say DTD here ?!
Am Son, 2001-10-07 um 16.42 schrieb 1002465752:
> I'm not not exagerating. A typical tip consists of multiple lines (2 to 5)
> and you can't translate them line by line. My typical emacs setup shows
> about 42 lines, while the typical distance between the original tip and the
> translation will
Am Son, 2001-10-07 um 16.50 schrieb 1002466228:
> our parser isn't homebrewn and is much better supported by glib than XML
> is. s-expressions are in my opinion easier to read and write for humans
Knowing that you're an EMACS user I definitely think this statement
could be true. :) I for one kee
Hi,
Daniel Egger <[EMAIL PROTECTED]> writes:
> First of all we should write an schema to make it validateable.
XML schema has only become a W3C recommendation lately and is
probably far from being finally standardized. AFAIK there are only
few (if any at all) usable tools out there that can va
Am Son, 2001-10-07 um 16.03 schrieb 1002463421:
> Also, one important drawback of keeping all translations in one file in
> CVS, and forcing translators to edit this file, is that it gets almost
> impossible to verify the integrity of translations. As a translator and
> creator and maintainer of
Am Son, 2001-10-07 um 15.32 schrieb 1002461554:
> Dia uses intltool/xml-i18n-tools for sheet files.
That's new then. They didn't when I was translating the sheets.
> Because one of the fundamentals of easy translation is simply to have
> the original text handy. This is so you can easily compar
Hi,
Carol Spears <[EMAIL PROTECTED]> writes:
> It seems that all any decent site would need would be this:
>
>
>
>
>
>0
>
>This is the first trip.
>
>
>
>1
>
>This is the second trip and it has bold text.
>
Hi,
Daniel Egger <[EMAIL PROTECTED]> writes:
> If we go for XML (which is definitely a good idea) we should use it
> also for our config files and drop the homebrewn parser. Maybe we can
> get away with simply using the new glib-2.0 functions instead of adding
> an dependency on libxml or simil
Am Sam, 2001-10-06 um 22.59 schrieb 1002401996:
> > To use gettext on has to have a file with C syntax;
> really???
I've heard there are Perl hacks as well. :)
> which would be easy, nice and probably very small.
Yes, but not very versatile...
> anyways, if we use another format (xml) and
Hi,
Daniel Egger <[EMAIL PROTECTED]> writes:
> Am Sam, 2001-10-06 um 19.05 schrieb 1002387943:
>
> > > That wasn't my point. I meant that it might be sensible for tips
> > > (instead of introducing the header kludge) and for plugin descriptions
> > > because it makes them more versatile and no
Am Sam, 2001-10-06 um 22.30 schrieb 1002400250:
> It seems that all any decent site would need would be this:
>
>
>
>
>0
>
>This is the first trip.
>
First of all we should write an schema to make it validateable.
Why do you want to have the nu
Replying to myself since I forgot some things...
Christian Rose wrote:
> While enforcing the use of UTF-8 solves the encodings problem, it is not
> feasible for many other reasons. One is simply the lack of support in
> many editors and many other text processing tools (and terminals and so
> on
Daniel Egger wrote:
> IF we need to add another dependency it has to be worth it. Solving
> problems by using XML for everything seems only clever to me. It does
> not make sense to use XML for tip files while plug-ins still keep
> in beeing broken (in the localisation context).
>
> > Someone men
On Sat, Oct 06, 2001 at 07:56:15PM +0200, Daniel Egger <[EMAIL PROTECTED]>
wrote:
> To use gettext on has to have a file with C syntax;
really???
> to have a header file where the original messages are defined and
> then use gettext with that.
which would be easy, nice and probably very small.
On Sat, Oct 06, 2001 at 07:33:28PM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote:
> have done it before. I can see at least one more advantages of using an
> external file: The tips don't stay in memory all the time. So we should
> probably go for it.
(just a sidenote: if tips were compiled-in
On Sat, Oct 06, 2001 at 06:06:19PM +0200, Guillermo S. Romero / Familia Romero wrote:
>Maybe next version should have Wilberpy as helper. The concept image
>was nice: "I see you want to draw a straight line".
Or rather: "I see you erase. Let me erase the rest of the image for you,
then save." *g*
Am Die, 2001-10-02 um 18.57 schrieb 1002041867:
> I'm all for it. I have already considered doing such a change in gimp
> HEAD. I'd favor a separate translation domain for the tips since we
> could avoid to bind to this domain until the tips dialog is actually
> shown. A header file with static
Am Sam, 2001-10-06 um 19.05 schrieb 1002387943:
> > That wasn't my point. I meant that it might be sensible for tips
> > (instead of introducing the header kludge) and for plugin descriptions
> > because it makes them more versatile and not bound to the distribution.
> I was referring to the t
Am Sam, 2001-10-06 um 17.23 schrieb 1002381819:
> Whatever the solution regarding GIMP tips turns out to be, translators
> want to be able to translate them from within po files. I hope everyone
> has agreed on that :)
not really.
> If you go for XML, I'd recommend using intltool. It's a set of
Am Sam, 2001-10-06 um 12.51 schrieb 1002365476:
> No prof. You've got it wrong. em means emphasis. It means the text
> should be given some sort of emphasis. The stylesheets then determine
> what that emphasis is. (italics, color change, etc.)
No, is HTMLism. There's no in DocBook for examp
Am Sam, 2001-10-06 um 14.33 schrieb 1002371616:
> > That wasn't my point. I meant that it might be sensible for tips
> > (instead of introducing the header kludge)
> What is 'the header kludge'? I never got that bit.
To use gettext on has to have a file with C syntax; the idea is
to have a he
Hi,
"Branko Collin" <[EMAIL PROTECTED]> writes:
> What is 'the header kludge'? I never got that bit.
I'll try to summarize what has been discussed so far. At the moment,
there are two proposed places to store the original english tips.
Either use a C file or a header that would look something
Hi,
Daniel Egger <[EMAIL PROTECTED]> writes:
> > > It's a lot more versatile then the header approach with my lovely
> > > friend gettext since the information is not spread over several
> > > files which need to be generated, compiled and installed. If we had
> > > more tips we could even categ
Branko Collin wrote:
> > > The file will get large and akward to edit.
> >
> > In the mentioned case this is not an issue. The tips are pretty small
> > anyways (just compare it to a uncompiled catalogfile) and for plugins
> > this isn't an issue at all.
>
> Someone mentioned how well Dia seemed
On 5 Oct 2001, at 16:06, Carol Spears wrote:
> Okay, everything I know about XML I learned by osmosis (ie, i slept
> with XML in a Nutshell under my pillow), but XML seems to make sense
> and be a lot less rigid than SGML.
To the contrary, XML is way more rigid than SGML, that is its
defining q
On 6 Oct 2001, at 12:37, Daniel Egger wrote:
> On Sat, Oct 06, 2001 at 11:23:11AM +0200, Sven Neumann wrote:
>
> > > It's a lot more versatile then the header approach with my lovely
> > > friend gettext since the information is not spread over several
> > > files which need to be generated, comp
On Sat, 2001-10-06 at 12:49, Daniel Egger wrote:
> On Sat, Oct 06, 2001 at 02:06:15AM -0600, Nathan C Summers wrote:
>
> > We can also use XML for its original purpose -- a markup language. Even
> > just adding an emphasis tag can allow tip writers to be much more
> > expressive.
>
> That's an
On Sat, Oct 06, 2001 at 02:06:15AM -0600, Nathan C Summers wrote:
> We can also use XML for its original purpose -- a markup language. Even
> just adding an emphasis tag can allow tip writers to be much more
> expressive.
That's an abuse of a tag. is a stylistic tag from the HTML days,
with XM
On Sat, Oct 06, 2001 at 11:23:11AM +0200, Sven Neumann wrote:
> > It's a lot more versatile then the header approach with my lovely
> > friend gettext since the information is not spread over several
> > files which need to be generated, compiled and installed. If we had
> > more tips we could ev
> perhaps I'm imaging something wrong here, but I think graphics would be
> overkill for the tips. Stuff like this belongs to the help pages if you
> ask me. It would probably help to allow links to help pages in the tips
> dialog and it would also be much simpler to implement than text flow
>
Hi,
Nathan C Summers <[EMAIL PROTECTED]> writes:
> We can also use XML for its original purpose -- a markup language. Even
> just adding an emphasis tag can allow tip writers to be much more
> expressive.
GTK+-2.0 allows some simple markup to be applied to labels and other
text areas without t
Hi,
Daniel Egger <[EMAIL PROTECTED]> writes:
> If you use XML for texts like tips or dialogparts then attributes
> are being used for specifying the language the text is in.
>
> A tip might look like this:
> Niemals GIMP schließen
> Never close the GIMP
>
> DIA for instance uses something alik
On 6 Oct 2001, Daniel Egger wrote:
> Am Die, 2001-10-02 um 19.14 schrieb 1002042874:
>
> > there is probably no need for XML as there are no attributes etc.
>
> If you use XML for texts like tips or dialogparts then attributes
> are being used for specifying the language the text is in.
We can a
Daniel Egger wrote:
> > No, as you say, a header file is probably the easiest solution,
>
> Actually if there was an XML parser this would be the simplest solution.
> It is just that we'd need a parser and I haven't evaluated the GMarkup
> part of the new glib yet.
Ok.
> > there is probably no
Am Die, 2001-10-02 um 19.14 schrieb 1002042874:
> No, as you say, a header file is probably the easiest solution,
Actually if there was an XML parser this would be the simplest solution.
It is just that we'd need a parser and I haven't evaluated the GMarkup
part of the new glib yet.
> there is
Am Fre, 2001-10-05 um 21.47 schrieb 1002311231:
> It is like the GIMP help. We write the help in DocBook SGML.
It is SGML right now but is written with XML compatibility in mind
so we would simply need to flip a switch (in every file that is)
to have full XML.
> It can be converted to cool stu
> XML is supposed to make information more portable into the future,
> right?
>
> GIMP is being used in classrooms lately, it would be nice if we have the
> option to print all gimp documentation in any form we should choose.
I'm not as familiar with XML conversion tools as I am with SGML, but
Hi Rebecca,
[EMAIL PROTECTED] (2001-10-05 at 2030.20 +0200):
>
> > it would matter if you could name an advantage it would give us. I don't
> > mind adding a simple XML-parser to GIMP-1.4 since it's pretty simple
> > using GMarkup from GLib-2.0, but I don't want to do so without a good
> > re
> it would matter if you could name an advantage it would give us. I don't
> mind adding a simple XML-parser to GIMP-1.4 since it's pretty simple
> using GMarkup from GLib-2.0, but I don't want to do so without a good
> reason.
hmm.. XML could be quickly converted to HTML and used on the web
Hi,
Carol Spears <[EMAIL PROTECTED]> writes:
> > I'm all for it. I have already considered doing such a change in gimp
> > HEAD. I'd favor a separate translation domain for the tips since we
> > could avoid to bind to this domain until the tips dialog is actually
> > shown. A header file with s
[EMAIL PROTECTED] (2001-10-02 at 1857.47 +0200):
> Hi,
>
> Christian Rose <[EMAIL PROTECTED]> writes:
>
> > Hmm, would it be possible to make GIMP tips translatable in a po file in
> > the future? That would probably ease translation, since gettext has some
> > nice features: it's easy to compar
69 matches
Mail list logo
