GNOME Bugzilla – Bug 547610
Profiles dialog is too technical
Last modified: 2011-04-06 05:27:38 UTC
Profile dialog in gtranslator is too technical for average translator. Translation teams are trying to lower the barriers for contribution and having a technically encumbered profiles dialog won't help for this matter. Currently profiles dialog has fiels like might very specific informations for languages like Language code, Character set, Transfer encoding and plural forms. These information are not something a regular translator should know. They should basically only set their Language with team e-mail and good to go. Rest of the information can be kept as a hidden configuration item for those needing specific changes (like Encoding). Also instead of team e-mail more descriptive term can be used, like Language Mailing List, or just Mailing List.
*** Bug 548925 has been marked as a duplicate of this bug. ***
Yeah, probably there are some fields in the dialog enough technical. I can set Transfer encoding to 8 bits by default. I didn't remember seeing another value for this field. Let me know if I'm wrong. I can also change the Character set field to a ComboBox with the most typical values like UTF-8, ISO-8859, CP1251, CP1256, etc... But I don't think the Language code is a specially technical information, besides to keep a list of languages updated with values for all this fields require a big effort and I'm not sure if it's worthy, maybe it would be better if each translation team give those values to their volunteers through mail list, web page... IMHO. What do you think?
Created attachment 117851 [details] [review] Improving the profile dialog This patch is an attempt to improve the profile dialog in order to do it less technical. It's to be applied in the git repository. I would like you to test it and let me know your opinions about it.
(In reply to comment #3) > Created an attachment (id=117851) [edit] > Improving the profile dialog > > This patch is an attempt to improve the profile dialog in order to do it less > technical. It's to be applied in the git repository. > > I would like you to test it and let me know your opinions about it. > The encodings array should be static to avoid problems.
Suggestions for the profile dialog: - Gettext's msginit has some way to find probable values for these field; it can even guess your email address! It would be great if Gtranslator used this feature somehow. - If the feature above can't be easily implementes, the language name and code could have a default value based on the translator's system settings. - The charset should be UTF-8 by default. I agree with the combo box suggestion; if arbitrary values are allowed, the valur must be checked when the user presses OK. - In fact, "UTF-8" is a character encoding, not a character set. I know it's wrong in Gettext, but Gtranslator doesn't need to reproduce the error. Please label the charset entry as "Encoding:" - I agree with setting the transfer encoding should be hard-coded as "8-bit". - The plural-forms text entry could also be replaced by a combo box, with values taken from the Gettext documentation [http://www.gnu.org/software/automake/manual/gettext/Plural-forms.html] or from Pootle or translate-toolkit (can't remember the link right now).
I *tried* to use gtranslator today for the first time, and I found it awful because of that initial profile configuration dialog. I already implemented gettext in several applications, but never came across the need for plural forms. So I didn't know what I have to add there. what is the difference between language code and language? Why are there no defaults for the charsets?
yeah this is probably the ugliest part of gtranslator and should need some love and automatization. I recommend you to open a file already translated in your language and check at the beggining of the file what you have to fill in gtranslator.
Here I leave a conversation about how we can implement this in a good way: Feb 06 13:53:35 <nacho> the thing is that in gtranslator the translator has to fill the langauge the lang code (i.e. it) and the plural forms Feb 06 13:53:45 <nacho> I have 2 ways to do this: Feb 06 13:53:52 <nacho> - use iso codes Feb 06 13:54:00 <nacho> - keep my own list of languages Feb 06 13:54:26 <nacho> the thing is that using iso-code I would still have to keep the list of plural forms Feb 06 13:54:58 <nacho> and I wanted to make that once the user mark the langauge fill everything automagically Feb 06 13:55:24 * shk has quit (Remote closed the connection) Feb 06 13:55:33 <pbor> the main advantage in iso-codes is that you get translations for free Feb 06 13:55:40 <nacho> yeah Feb 06 13:55:59 <pbor> maybe you can do it this way (but I do not know gtr so I may be wrong) Feb 06 13:56:15 <pbor> create a boxed type for the available langs Feb 06 13:56:24 <pbor> as we do with encodings in gedit Feb 06 13:56:41 <nacho> yeah had that in mind Feb 06 13:57:05 <pbor> when creating the object fetch stuff from iso-codes Feb 06 13:57:25 <pbor> and merge the plural thing info from an array or something Feb 06 13:57:45 <nacho> ah! nice, thanks a lot Feb 06 13:58:05 <pbor> maybe you can also put the plural info in a separate file Feb 06 13:58:30 <pbor> like lang:pluralinfo for each line Feb 06 13:58:54 <pbor> and either load it at runtime or generate a .h file at build time Feb 06 13:59:00 <nacho> yeah, I'd also like the current language maintainers to fill that array Feb 06 13:59:20 <pbor> yep, easier than patching code Feb 06 13:59:48 <pbor> and maybe it could be done with intltool itself Feb 06 13:59:58 <nacho> with intltool? Feb 06 14:00:21 <nacho> you mean to get the lang plurals from it? Feb 06 14:00:37 <pbor> mmm... not sure if it makes sense, but I was thinking that maybe another way could be: Feb 06 14:01:04 <pbor> have a string like plural_form marked for translation Feb 06 14:01:06 <pbor> mmm Feb 06 14:01:12 <pbor> no it does not work Feb 06 14:01:34 <nacho> yeah I thought about that some time ago but I discarded it Feb 06 14:01:39 <pbor> it would force the italian translator to run gtr in italian Feb 06 14:01:44 <pbor> yeah Feb 06 14:01:45 <nacho> yeah Feb 06 14:01:58 <pbor> I think a separate file is the best Feb 06 14:02:04 <nacho> ok thanks a lot
I'm proud to say that I've finally implemented this. It is now in master. Although I'm leaving this opened as this is only implemented for the preferences profile dialog but not for the assistant.
Also say that if you are interested on getting your plural forms you will have to edit this file: http://git.gnome.org/browse/gtranslator/tree/data/gtr-plural-forms.ini Feel free to add it and push it.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Ignacio, it's bice to see this solved. I'll ask someone from the pt_BR to fill the information. But wat do you thibk of importing this once from the translate-toolkit source code? http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/ I don't remember the exact place, though.
For me is fine, feel free to port it :) There are several places where they have such a thing but I was lazy to make a conversion script. Also I've read the other day that you were doing some program in vala for comparing strings, I would be interesting in such a plugin for gtranslator if you feel like making it. See that now you can develop plugins for gtranslator in c, vala and python.
Thanks, but you shouldn't rely on me for software development. My own pet project is stalled for more than an year, and I am lousy at this. (Too good it's not my day job!)