Re: [Grecipe-manager-devel] Translation of defaults_en.py (+ SQL discussion)
GNOME Recipe Manager w/ nutrition information and other useful plugins
Status: Beta
Brought to you by:
thomas_hinkle
From: Thomas M. H. <tmh...@gm...> - 2005-06-02 02:29:25
|
Re-CC-ing the list. I didn't mean to take the conversation off-list the first time but did; hope you don't mind me posting back to the list again. I think other folks might have other observations of inconsistent strings in Gourmet, and may also be interested in the SQL discussion (sorry, perhaps this should really be split to two threads, but there's only so much I can do just now :) On 6/1/05, Leandro Guimar=E3es Faria Corcete Dutra <le...@du...> wrote: > Em Qua, 2005-06-01 =E0s 17:38 -0400, Thomas Mills Hinkle escreveu: > > Great! I'll add your defaults file to the gourmet distribution -- >=20 > That'd be great! >=20 >=20 tmh> > where can I get the file? >=20 > I can publish it in the web, attach, send in the body, to yoursel= f or > to the list. It ain't big, so it makes little difference to me. Go ahead and attach it and I'll commit it to CVS. CC me as well as the list in case the list rejects the attachment. [Context: talking about inconsistencies in strings caught during translatio= n] tmh> > Ah -- thanks for catching these. I've added the Mealmaster tmh> > normalization to my TODO list (I'll do a quick google to see which o= ne tmh> > is more standard and then standardize to that). Can you tell me what tmh> > the other irregularities were that you noticed > > I noticed some phrases have some words capitalised, others only t= he > first word; that sometimes there are copy rights and trademark symbols > following brand names, sometimes not; that sometimes there is a colon > between text and data, sometimes not. >=20 > I haven't really looked at the context, so some of this stuff I n= oticed > may not be inconsistent at all, but I was under the impression that > should everything be normalised there would even be less strings to > translate and maintain. That makes sense, I think. I'm actually not 100% sure whether things like ":"s translate universally, or whether some languages might use something else to separate a label and control. Some of this separation I could provide programatically -- in other places it would be harder. Specifically, it's easy to change strings that come from my python files directly from e.g. _("Recipes: ") to "%s: "%_("Recipes"). It's hard/impossible to change the equivalent strings in a glade file since the strings are grabbed automagically. > I should probably have taken notice of each instance I was bugged= by a > perceived inconsistency, but I have other worries now... Of course -- I'm posting to the list in case anyone has any lingering inconsistencies they've noticed and kept mum about until now :) [Context -- aside about SQL] > > > Thanks for an interesting program! I just wished it stored s= tuff in a > > > real ISO SQL database such as PostgreSQL... > > tmh> > Ah -- there is a basic SQL backend but it's currently not functional= . >=20 > Ah, that solves the mystery... I did notice I translated several > sub-SQL-related strings but never saw anything in the running program. >=20 tmh> > I don't know SQL well and didn't want to learn it in order to do thi= s tmh> > project > Perhaps you'd find it more fun to learn the relational model itse= lf, or > at least Tutorial D... helps making sense of SQL. Perhaps -- it may be that I already know something of the "relational" model -- I'm not sure how much I'm just missing the terminology and how much I still don't know the actual concepts around this :) tmh> > (SQL bindings seem like a pain to me because they require me tmh> > to think in SQL rather than python; >=20 > That's just as it should be... SQL is a misimplementation of the > relational model, but it is still different enough from everything else > to need a different mental approach. tmh> > metakit bindings on the other hand tmh> > are very pythonic, letting me stay in my preferred medium). >=20 > Now you flew over my head... Sorry -- by "pythonic" I mean that they work like other things in python. In particular, metakit makes tables look like "Views", which are objects that behave essentially like lists in python -- making it easy to loop through them, filter them, etc. with standard python methods. It means that program with metakit makes working with a database look like working with just about anything else in python, whereas programming with e.g. SQLite tends to involve long strings of SQL showing up in python. Since I tend to think of strings as not-part-of-my-program, it feels like a terrible hack to do all kinds of string manipulations in order to programatically create tables etc. in the SQL dialects. tmh> > I also tmh> > didn't want to require my users to install/administrate a database, = as tmh> > I think that would seriously limit my userbase. > Shame on me for now knowing for sure, but I guess PostgreSQL has = a > means to install an embedded database, where the user doesn't even need > to know about it unless he wants to. If so, it would be a viable backend down the line :) tmh> > That said, I have written an experimental SQL backend which could tmh> > easily be expanded to support PostegreSQL. I've been waiting for a tmh> > more experienced SQL developer to hop on board and push the SQL end tmh> > into working better so we can see if it will in fact result in any tmh> > kind of performance gains. > Perhaps not... SQL never realised the full capabilities of the > relational model, performance or otherwise, so its benefits are more on > the side of searching, manipulation, sharing and scalability. >=20 > That said, it usually gives you more than decent performance for = all > but the most extreme cases if you just normalise your data and think > relational. >=20 > Perhaps if you have your current data model at hand I could have = a look > at it and propose something. But I fear you will have to learn to think > relational by yourself, perhaps with some Date handholding, and worse of > all think about how to migrate current data. Ah -- well, there's a bug report out with some basic improvements that should be made (e.g. making arbitrary IDs integers). I'm sure there are many others too. The db can be model made sense of (hopefully) by reading rdatabase.py in src/lib/backends/, approximately lines 30-99. tmh> > Out of curiosity, why would you prefer that Gourmet store its data i= n tmh> > an ISO SQL Database? AFAICT, the database backend *should* be tmh> > transparent to the user. >=20 > Well, I'm a DBA... and it hurts to think that people are using > substandard engines like SQLite or MySQL where lotsa stuff that should > be done declaratively by the DBMS needs to be done programatically. >=20 > Besides, I have this grand vision where eventually we'll use GNU = Hurd > to switch to a relational functional OS, and the sooner apps start > storing in SQL or, ideally, some valid D, the easier the switch will be. Hurd, eh? I'll cross my fingers that gourmet gets working SQL support before the Hurd becomes fully operational. Tom |