Hi, Chusslove Illich <[email protected]> writes:
>> I've read quickly through it and while I recognize some legitimate >> drawbacks of current system, I don't see anything justifying such deep >> changes. > > There are no changes, only additions. > >> I don't expect any significant number of projects to migrate and so we'll >> end up with having to handle both old and new bugs. > > The proposed design is such that there is no need for all-out migration. > Firstly, the complete system can be ignored, and then nothing changes. > Secondly, ordinary and new generalized calls can be used in the same code, > which makes it possible to gradually migrate, or to only use the generalized > call where judged advantageous. Finally, the design is such that all-out > migration is not that hard either, given that I did this once for three > million lines of KDE code in about a week span (section 7.1). You wrote in the last post: "Practical implementation, I guess, would take form of another library (incl. language bindings) in the Gettext distribution," I guess this would increase the maintenance burden of Gettext. Does it really need to be included in the Gettext distribution, rather than external library (for example, Python's gettext module adds a nice interface to *gettext function family, but it is distributed in the Python distribution)? > As for bugs, as mentioned above, for the past five years I don't recall > there being a bug reported on the translation system itself, or any > particular increase in bugs in translation caused by the system. So, has the translation system already been practically used? Regards, -- Daiki Ueno
