Re: PHP+gettext

[Joshua Eichorn <jeichorn JoshuaEichorn com>]

I would just like to make the point that we should use whatever systems the
majority of translators out there want, not some systems that
seems nice to use English speaking developers.  Translations won't happen
if translators have to learn new systems and since the gnome translators
already know gettext this seems like the only sane solution to me.
-joshua eichorn

Christian Rose wrote:
> Shawn T Amundson wrote:
> > > Your argument was that gettext is bad (to which I obviously disagreed),
> > > you didn't mention anything about how your proposal would work with
> > > regards to translation or why it would be better.
> > >       
> > The reason it's better is that the text/html is completely seperated
> > from the code.  When you write stuff that way, you don't need to have
> > translation tables.  (Actually, you still might have to have translation
> > for dynamic data, but in general it's not necessary.)
> >       
>
> Ok.
> Do you still mark messages for translation, or is everything in the
> "text" assumed that it should be translated (that's a wrong assumption)?
>
> Do you have all translations in one file? How do you solve character
> sets issues?
>
> Keeping different translations in different files like gettext does also
> has many administrative advantages since different translations are
> usually done and maintained by different people.
>
>
> > Text/html fragments are saved as templates.  Templates are combined to
> > create a webpage.  The simplest example is a template which contains a
> > complete html page, say index.ftl.  On disk then, you have:
> >
> > templates/en/index.ftl
> >
> > And the translator creates:
> >
> > templates/fr/index.ftl
> >         
>
> Okay, so you keep different files for different translations.
>
>
> > If the translator hasn't het created the French version, it would fall
> > back and show the English version.  CVS can be used to determine what
> > exactly has changed so that the translators can update their versions.
> >           
>
> Now that is broken. First, even if we use cvs in gnomeweb, I assume your
> solution is aimed to be more general than have a cvs setup as a
> requirement.
>
> Second and most important: cvs diffing does simply not work for
> translations. You can't use cvs diff and ordinary patching because,
> well, one is the original language and the other one is a translation.
> You have to have a merging system that allows for  changes to be merged
> directly into the translation.
> Else, what you are suggesting is basically that translators should use
> cvs diff every day to manually copy and paste changes in the English
> text into their own existing translation (of maybe ten thousand of lines
> or more) at the correct place, and at the same time translate it? Sounds
> very far from realistic to me. How much do you like copy and paste? It's
> a nice feature, but trust me, you don't want to *have* to do it every
> day.
>
> Contrast thi!
> s to gettext, where you can get a new pot file with one
> command, merge that pot file with your translation with another (usually
> you have those two in a script, that's basically what "xml-i18n-update
> LL" does) and suddenly you have updated your translated message catalog
> to reflect the current status. Strings that are added/changed and where
> the translation needs to be added/revised are marked and immediately
> visible.
> The original string is immediately visible directly above your
> translation so that you can compare and translate.
>
>
> > That's a very high level overview showing most of what a translator
> > would need to know.
> >             
>
> Yes, but you've completely ignored mechanisms for maintaning the
> translation (updating and merging), one of the most important things
> with a translation system. gettext solves that. 
>
>
> > > > Would you be interesting in helping translate www.gtk.org into Swedish?
> > > >                   
> > > Sure, if you use gettext :-)
> > >                   
> > No, that's not likely.
> >                   
>
> Too bad.
>
>
> > > Then I can, among others:
> > >       * Translate partly automatically using existing Swedish translations I
> > >       have in a po format translation memory (~4MB existing po format
> > >       translations)
> > >
> > >       * Maintain and simply update the translations (the wonders of msgmerge)
> > >
> > >       * Easily detect new or changed strings and update those, and know where
> > >       in the pages they come from
> > >
> > > I don't know if you noticed that SourceForge started an i18n project a
> > > year ago. Well, SF i18n is dead now (only very few strings are possible
> > > to translate, and nothing happens, even though there are a lot of
> > > willing translators). The reason? Choosing a home-invented and by all
> > > means stupid (from i18n view) translation mechanism.
> > >                       
> > Well, I'm very interested in learning how to make Fabric easier to use for
> > translators, so I'm listening.
> >                       
>
> You can use a gettext interface. Why do you think xml-i18n-tools was
> created(*) in the first place? Well, because gettext is a *very*
> powerful mechanism, and reimplementing it and everything it does for
> every new code is tremendous and unnecessary work.
> What I mean ny interface is that you extract strings to po message
> catalogs, and you convert the translations back to your preferred format
> at a compile stage.
>
> (*) xml-i18n-tools is a wrapper system used in GNOME that lets lots of
> different sources (like many XML file formats with strings, or .desktop
> files) be translated with gettext. 
>
>
> Christian
>
> _______________________________________________
> gnome-web-list mailing list
> gnome-web-list gnome org
> http://m!
> ail.gnome.org/mailman/listinfo/gnome-web-list
>