> [: David Faure :] > There's no way to keep the [insertCatalog] method for source compatibility > and implement it somehow on top of the new solution?
The problem is that insertCatalog no longer has a meaning. Its purpose was to add more translation catalogs into the current process, and all of them would be searched for translation on a given i18n call. While in the new system, all i18n calls are bound to a particular catalog (either through TRANSLATION_DOMAIN define or setApplicationCatalog). > I'm afraid of the porting effort created by all these source incompatible > changes. If we can minimize that, it's all for the better. For porting, my focus was on the case where for each library/application there exists a different maintainer who will perform the update. In this case, it is not much effort: throw out any insertCatalog methods, replace with one TRANSLATION_DOMAIN define in private header (for libraries and applications) or one setApplicationCatalog call (easier alternative for applications). Of course, in reality there is sometimes no maintainer, or an "incidental" maintainer with piles of other things in the queue, and then porting becomes some effort. I'll help :) -- Chusslove Illich (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
