Re: Translating schema files (was: Re: Survey results (yay!))
- From: "jbowtie amathaine com" <jbowtie amathaine com>
- To: aloriel gmail com
- Cc: GNOME i18n list <gnome-i18n gnome org>, Ask Hjorth Larsen <asklarsen gmail com>, Simos Xenitellis <simos lists googlemail com>
- Subject: Re: Translating schema files (was: Re: Survey results (yay!))
- Date: Tue, 2 Nov 2010 13:44:30 +1300
2010/11/2 Jorge González González <aloriel 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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]