I'm vividly reminded of my software engineering professor's lecture on
Friday, where he talked about how after someone has done something, when
that person talks about it, they assume that the person listening realizes
a lot of details that speaker doesn't explicitly say, yet the listener
does not
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
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
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
[ Sun, 7 Oct 2001 03:32:39 -0600 (MDT) ]-[ Nathan ]
..__. . _..___ .._... ._.__.. _ ..__ _._ ._.__.._ __ . _
[monstrous snip]
I haven't really been reading all the details, but I have the
gist of it ;)
There is a lot to be said for images _and_ text doing the work of
helping the user navigate
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.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
[EMAIL PROTECTED] (2001-10-07 at 1435.12 +0200):
> 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 s
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
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.
>
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,
Nathan C Summers <[EMAIL PROTECTED]> writes:
> > and [links] would also be much simpler to implement than text flow
> > around image boxes (unless you want gimp to depend on gtkhtml2 for the
> > tips).
>
> I hadn't considered implementation. I certainly don't want to write code
> to handle
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
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.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
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 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 Sam, 2001-10-06 um 19.34 schrieb 1002389654:
> more info, and a possible candidate for bug, and a possible workaround:
I just glanced over your bugreport but it seems quite valid and
good reasearched to me, posting it here was definitely a good idea
but we'd really appreciate if you added it
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
Hi,
I think the mails on the list show that there is a lot of confusion about
how intltool (former xml-i18n-tools) works and how it can be used for our
purposes. We seem to agree that a simple XML format for the tips would be
nice and extensible enough for future additions. What remains is the
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
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
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
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
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
> The format I've outlined above still has one problem unrelated to i18n:
> Do we want to allow paragraphs in tips for nicer layouting and how do
> we represent them? By adding a ... tag ?!
No. Any tip long enough to require an additional paragraph should not
be a tip. That information should
done. Bug 61894.
--- Daniel Egger <[EMAIL PROTECTED]> wrote:
> Am Sam, 2001-10-06 um 19.34 schrieb 1002389654:
>
> > more info, and a possible candidate for bug, and a possible workaround:
>
> I just glanced over your bugreport but it seems quite valid and
> good reasearched to me, posting it
Sven Neumann wrote:
[snip]
> The advantage is that translators can use their standard tools and can
> decide to edit the po file in whatever encoding they like. The parser to
> read this file should be pretty much straightforward including the
> language handling. This solution will require some
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
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
Am Son, 2001-10-07 um 18.09 schrieb 1002470948:
>
>
>
> Welcome to The GIMP
> Willkommen zu GIMP
> Bienvenue sr GIMP
>
>
> The advantage is that translators can use their standard tools and can
> decide to edit the po file in whatever encoding they like. The parser to
> rea
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
This is gimp-print version 4.1.99b3, the third beta release leading
up to the 4.2 stable release. This release is not 4.2.
This software includes the Print plug-in for the Gimp, and GhostScript
and CUPS drivers. The support for printers in GhostScript and CUPS is
identical to the support for th
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 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 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
Hija,
I just updated GIMPs help in the 1.2 branch to the latest stuff
from the gimp-help CVS. It also introduces a few new files and
directories and thus I had to touch the Makefiles. It would be nice
to get some feedback from you whether it works or not on your
machine.
Thanks from this place
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
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
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
"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
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
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
> Am Son, 2001-10-07 um 18.09 schrieb 1002470948:
>
> >
> > Willkommen zu GIMP
just a nitpick, that should have been "de-DE" etc. (I hope the next xml
revision will allow the much better three-letter-iso-639 codes).
--
-==- |
---
44 matches
Mail list logo
