Hi! Martin Ereth wrote:
>>>In case we're going to use Qt's translation mechanism in the first place. > > That would be the easiest solution. But also the worst one. What if we want to add a gtk+ GUI one day? Or a *real* command-line version without the GUI overhead? The former is already on my wish list, by the way. What dvbcut badly needs is more separation of the functionality and the GUI. And a clean interface between them. If we use a Qt feature for i18n/l10n, we're going in the wrong direction. Unless we only translate the GUI portion (i.e. the 60-odd menu items). Besides that, everybody else uses gettext. I consider it a major design flaw that Qt provides its own translation mechanism, instead of proper hooks for gettext. If your Qt application uses any non-GUI libraries, for example, you end up using both mechanisms in parallel: gettext for the libraries and the Qt translator for the GUI. That's plain stupid, in particular since no serious application can do without third-party libraries these days. With regard to that, dvbcut is not an exception. -- Michael "Tired" Riepe <[EMAIL PROTECTED]> X-Tired: Each morning I get up I die a little ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DVBCUT-devel mailing list DVBCUT-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dvbcut-devel
