2010/11/2 Jorge González González <alor...@gmail.com>: > I guess we should distinguish between two kind of errors: > * Errors from the application, which should be translated and the user > will, for sure, see > * Internal errors, usually shown at the command line, which the user > *may* see, but which are the ones I mentioned that when you search for > them in other languages, rather than English, you can't find info. > > And I guess the hackers know perfectly which are both of them. >
To be pragmatic about it, I wouldn't care for smaller modules (say, <100 strings after schema filtering - gtk-engines, libgnome-keyring). For mid-size modules (say <500 strings after filtering - nautilus-actions, gdm, gedit maybe) I only really care if the error messages take up >25% of the strings to be translated. For the larger modules, leveraging existing message context/translator comments or creating GNOME goals to supply said context would work so long as D-L can do the filtering. Most of the internal/developer-oriented errors are stuck in core libraries, so you could start just by looking at filtering those. In gtk+, as an example, all the stock messages already have a message context IIRC. Filtering down to those would give me a big chunk of the high-visibility strings in that module with no additional work - it isn't all the user-visible strings, of course, but for a casual/first-time contributor it's far less intimidating than a version with all those highly technical error messages. _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
