Op Di, 2010-11-02 om 12:09 +0200 skryf li...@kambanaria.org: > Just to suggest an idea: > > The predominant message thus far has been "Developers you should do more > work, so that we can translate less of your application". Perhaps we can > improve it a bit.
To be fair, I think several suggestions are about solving this without developer intervention or any changes in their workflow. And it is really about spending the same amount of time on the most meaningful stuff, not less work. I'm sure developers would prefer a UI translation over schemas translation if they had to choose between them. > Speaking as a member of a supported language: > > The style of the translation of strings is different depending on the > place they appear. > > - Interface strings demand maximum clarity in minimum characters. > Additionally in testing - you can change them to improve the layout of the > windows, menus, etc. Plus you need to check keyboard shortcuts. > > - With schema messages you translate to explain things, so you can really > write sentences and paragraphs to be sure that the user understands the > gconf key meaning. > > - Console messages have demands on their own. On the one hand they can be > reformatted to fit the most usual terminal size (for example width of 80 > chars). On the other hand a team can decide to use a more limited > character set for console messages (for example the whole range of UTF-8 > characters for interface, limited subset known to work in terminals, or > fitting popular for the locale 8bit charsets). > > So explaining the different types of messages has *strong* benefits for > teams that intend to translate the strings. The messages are not being > singled out for negligence. Providing the type will improve the > translation and review. Please note that I am using the term "console > messages" - those that appear on the command line. I do not think the term > "error message" used in the discussion thus far had a clear enough > definition - I do think people wrote about different issues. I agree that there are other advantages to splitting. For example, if we do integrate some knowledge of this into the build system, we can avoid putting the translations of the schemas into the .mo files, which could reduce their size, making all sorts of people happier, I guess. Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/latest-pootle-news _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n