On Di, 2006-06-13 at 00:42 +0300, Gintautas Miliauskas wrote: > Hello, > > I have attempted to sketch how I would imagine the new API. An > interface description (that can also be validated) in sort-of-Python is > attached. It's not something completely from scratch; I have looked at > the present code a bit, and at the docs you have on the wiki. At > present the model is very simple and does not include advanced > features, but the idea is there and it can be extended easily. > > I would like the coders to have a look and say if they like it. As > this is a sketch, it did not take much time to put together, so I > don't mind at all if we decide to throw this away. >
I'll just comment loosely on a few things as I notice them or think about them. Forgive me if my comments are not quite in the direction or on the detail level you were asking for :-) ILanguageInfo: ISO639 is not enough - we need to include the possibility of ISO3166 country codes, although they shouldn't be mandatory. Please explain what you mean with a 'module'. To use gettext terminology, does it correspond to a PO file in GNOME, or to a directory of files, or to a PO domain? For ISuggestionList you can look at the existing lookupserver/lookupclient implementation - it is still very basic, and I have some uncommited work there, but is a start and already exists. In terms of the statistics, I don't know if we necessarily need separate types for a project and for language. We need to determine the needs, but it might be simpler to have one type. IProject: we might need information like accelerators, etc. - what we currently call checkerstyle. Probably just a checkerstyle, although we might want to define an interface for that as well, some day in the future. We might want to store optional version control information. I would suggest aligning the terminology (and API in general) with what we have in the base classes (which was based on XLIFF, as I recall), so for example rather 'unit' than 'message' or 'translation'. In terms of data, we'll probably need fairly rich ways of supporting comments, context, states (fuzzy, needs-review, etc.), formats (c-format, etc.). There are _lots_ of stuff in XLIFF, we can't realistically support all of it immediately. But perhaps we should at least support most of these that I mention. People will probably disagree about what is important, but this list is a start. On the other hand, we want to work towards handling process information, etc. so we'll probably need a lot more. In terms of actions, we'll need methods for pushing updates, specifying which actions to take and in what way (join, overwrite, overwrite if empty, ignore, turn into suggestion, etc.). We'll probably want some way to trigger an action, like updating from version control. We'll probably need some authentication system, although this whole area probably needs far more consideration. > I wanted to use Zope interfaces for declaring the API, but decided that > it may not be worth it here to add another dependency. > > I ran into two design problems here. I think that they would hold for > any API, not just the one I sketched, so please bear with me :) > > 1) how to add a new item to a container, let's say, a new module to a > language translation set. I see two ways: > * use a special factory class (Abstract Factory pattern) that builds the > needed objects, then add them (I prefer this) > * have each container implement the add() method so that it instantiates > an empty item, adds it and returns it. The new empty item can then be > updated with the required data. This works a bit like the Prototype > pattern. > I don't quite see the advantage of the first approach, since I don't foresee a complex requirements for item creation. For base.TranslationStore, we already have addsourceunit(source), so perhaps we can use something similar unless there is need for something else. > 2) when to save data. Again, several choices: > * straight-through: always carry out the operation at once. Grossly > inefficient for strings (imagine adding strings to a module one by > one), but might work for higher-level containers > * completely explicit: serialization happens when you explicitly call a > method save(). This is prone to bugs and not very nice design: it may > break the abstraction. > * transactional: when you modify an object, it marks itself as > "dirty". The Pootle main function calls "db.startTransaction()" at the > beginning of processing a request and calls "db.endTransaction()" at > the end. endTransaction() would collect the "dirty" objects and write > them to disk. I like this one best, as it leaves it to the > implementation of the API how to efficiently deal with changes. > The third approach might have been necessary if we had big data dependencies, but it might be overkill. Then again, I guess we can implement something simple within that API. I'll let others comment on this more. I don't see why the second is necessarily that bad, but we'll discuss this more later. _______________________________________________ Translate-pootle mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/translate-pootle
