[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Regarding QaMoose

--- Moustafa Mounir Elqabbany <elqabbany at sunnipath dot com> wrote:
> It appears to me, and I am no expert, that gettext andits supporting tools 
> were only ever intended to accomplish translation of software packages, and 
> not to produce a general purpose dictionary. To me -- and I want to reiterate

> that I have very limited exposure --these tools lack basic features that are 
> necessary to produce a general dictionary useful to people interested in 
> natural, non-technical language.

I would tend to agree with that - more to follow.

> If QaMoose is going to evolve into a general-purpose dictionary, it cannot 
> rely on PO files.  These files don't have thes tructure to support all sorts 
> of features that are necessary forgeneral-purpose translation.

I don't think you are looking at the right end of this issue.  QaMoose is
a mere simplistic front-end viewer to the wordlist.  What you are really
talking about is Wordlist's format - again more to follow :-)

> On the otherhand, QaMoose *can* make use of the wordlist project, by taking 
> the input and putting each translated entry into an "uncategorized" binunder 
> the untranslated entry's heading.  The people who work on QaMoose can then
> at least start with the uncategorized translations and categorize them as a 
> first step.

This is one way to do it (it assumes you have an people willing to do this
work vis the web and a means to reflect back that info in a text-readable
format - a complexity not worth getting into).

>   We open the floor for the design of a truly useful QaMoose.

That assumes that QaMoose is useless which is not the case, but I fully
agree, in principle, with what you are getting at with regard to a
prim and proper Dictionary format/syntax, et.  Let me inject a few
more things into the mix to better structure a thought.

Wordlist and QaMoose are the only GPL (fully free) options out there.
We wanted the Wordlist to be an open source project which other projects
can use and benefit from.  As such, I, for one, would be very uneasy about
going a route which uses our own proprietary structure to bring forth the
categories/terms/settings/etc that were mentioned.  If there is an open
standard that addresses these things, then by all means we have something
to shoot for and go after.  And to find out if there is such a thing out
there would require some research and some directed emails at various
sites to see how best to approach it.  Since we wanted to get the ball
rolling (and since NO work will ever be lost with regard to the Wordlist),
it was decided to use the .PO format (all translators after all are familiar
with the format, procedures, etc and the shear number of terms we are
holding is staggering).

One final thought - we can still accomplish what you are eluding to with
regard to categories with .PO files given we know exactly how we want to
structure things and how things will ultimately look.  The point that needs
to be made here is that it is much easier to move data around versus
entering the data (ie. its easier to reshuffle strings then to go lookup
the meaning of some complex terms to translate 'em) - thus, one should not
sit about and wait for this to happen but work on both issues (translation
and re-structuring) in concert.

Hope that makes sense.

BTW: __PLEASE__ don't send HTML mails and stick to 80-character line widths.


 - Nadim

Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.