Hello, I'll try to be short this time, I want to clarify some misunderstandings. > Independently of the backend storage, FOSS projects and translators > (the users and customers of the system) work with files, which must > interact with Gettext, translation editors, etc. If the API does not > produce files, then another layer on top will have to do it, creating > a new unnecessary layer. po (or XLIFF) are presentation formats and they belong in a separate presentation layer rather than in the data storage layer in any case. > >Trying to stick to a standard format (XLIFF, .po or anything else) > >for backend storage is not a good idea because it will be > >unnecessarily limiting. The standards have their own specifics > >which we may not care about, so there's the overhead of storing > >things the 'standard' way, even if it is not convenient. Eventually > >the format will simply not be enough. We will want to keep lots > >more metadata (e.g., string history, string submitter, date, ...). > >Storing that in external files, separated from the actual data, will > >be increasingly uncomfortable. > > You should read the standards. They are made by people who have been > working in localisation for many years, have extremelly clear > understanding of what is necessary, how to structure it and how it > should be encoded. We DO care about them. If there was no PO > standard, each FOSS application would have to do its own translation > editor, and we would not be here now. We produce standard files so > that standard translation editors can be developed and used. There is > no modern computer science without standards. I was not arguing about standards. I was arguing about using a standard XML format for the backend. I was not aware that XLIFF is extendable, but I still think that using XML for a database is not a good idea even though it is feasible. > The debate of files/DB backend is -nevertheless- independent from the > use of standards. I was speaking explicitly about the backend storage format. > You DO commit to a format, it just happens to have very efficient > ways of handling data (in general) Agreed, you do commit to a data structure, but at least there is no parsing involved. > If there is change, it will not be tomorow. It requires clear > planning and some security that the new approach is better, which we > will only have through experience. This is why I propose in my prior > mail developing an experimental second DB based back-end (which we > are prepared to fund), to ensure that all data can be easily mapped > and that it works better. If it comes out to be clearly better, we > will be the first ones to go for it. I couldn't agree more here. Let's close this case. > You opinion on the back-end is important, as many others, but please > remember that there are other people involved, and that there are > reasons why we do things the way we do them. At some point we might > need to change the way things are made, but we need to be sure that > we are moving to a better approach. Opinions are not enough. Sure. I was not concerned with inaction but with some basic misunderstandings. -- Gintautas Miliauskas http://gintasm.blogspot.com
Attachment:
signature.asc
Description: PGP signature