Translation inconsistency
Hi, as pointed out before, we have an inconsistency between the core and the plugins when it comes to the point if PDB blurb and PDB help should be translated or not. The situation right know is: In the core the short description and the longer help strings for the PDB functions are not marked for translation. This decision was made since the PDB help strings are considered to be targeted mainly at developers and script-writers. It would be a lot of work to translate them and even more work to get the translations correct and to keep them uptodate. So it was considered not to be worth the effort. In the plugins domain however we did not spend too much attention and have marked those strings for translation. Well, a lot of plug-ins don't give useful help strings, so the amount of work for the translators is not as large as it would be for the core. All those strings only ever appear in the GUI when using the DB-Browser. So, the question is, does it make sense to translate them and is it worth the effort? Removing the strings from the pot-file would reduce the number of messages in the gimp-std-plug-ins domain considerably. They might be useful on the other hand, but the same applies for the core PDB strings. I have no idea how to handle this. Just a few suggestions: (A) do nothing, ignore the problem (B) don't mark the strings for translation, not in the core, neither in the plug-ins (C) mark the core PDB strings for possible translation too Any ideas, comments anyone? Salut, Sven
Re: Translation inconsistency
On Mon, Jan 31, 2000 at 01:53:47PM +0100, Sven Neumann wrote: In the core the short description and the longer help strings for the PDB functions are not marked for translation. This decision was made since the PDB help strings are considered to be targeted mainly at developers and script-writers. It would be a lot of work to translate them and even more work to get the translations correct and to keep them uptodate. So it was considered not to be worth the effort. Sounds fine to me so far, biased as I might be Any ideas, comments anyone? I'll buy (B) -- we do not translate C keywords, variable names, or any other components visible only to the developer. Nor do we translate internal errors, bug reports or this list. Therefore to contribute effectively as a developer you have to learn English anyway. If you need to tell USERS something important then it should not be in these strings, you should rather write a paragraph for the GUM. (B) don't mark the strings for translation, not in the core, neither in the plug-ins Nick.
Re: Translation inconsistency
My vote: (B) don't mark the strings for translation, not in the core, neither in the plug-ins There is enough work for translators anyway, without having to translate stuff intended only for developers. --tml
Re: Translation inconsistency
On 31 Jan, Sven Neumann wrote: (A) do nothing, ignore the problem (B) don't mark the strings for translation, not in the core, neither in the plug-ins (C) mark the core PDB strings for possible translation too Kick them -- Servus, Daniel
Re: Translation inconsistency
If you need to tell USERS something important then it should not be in these strings, you should rather write a paragraph for the GUM. (B) don't mark the strings for translation, not in the core, neither in the plug-ins It depends on what is meant by having something important to tell the users. If the information is just letting the user know how to do something or what a particular feature does this should be in the manual. If its a message as a result of a run time situation (input needed from the user, status message, or an error message) this should be translated based on the users specified language. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: Translation inconsistency
(B) don't mark the strings for translation, not in the core, neither in the plug-ins BTW, _this_ is the solution 1.2 has (most probably) settled for. It depends on what is meant by having something important to tell the At the moment, it depends solely on wether it can be made to "work" in 1.2, and it simply cannot. In 1.3 we have lots of similar i18n problems to solve. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Translation inconsistency
On Mon, Jan 31, 2000 at 09:40:21PM +0100, Stanislav Brabec [EMAIL PROTECTED] wrote: I'm not happy to hear about (B). I have already translated hundreds and hundreds of such string and I don't: The question is, where is it trnaslated? You can't translate it in plug-ins, you need to trnaslate it in the programs displaying the strings, e.g. the DB Browser, the PDB Explorer or other tools. -- want to trash my work Hmm... I don't think we can make good use of it in 1.2. Maybe it would be best to preserve them for 1.3, when new ideas have a chance to get implemented? -- The reading is very interesting (and sometimes only reasonable explanation, what plug-in does), that there is good reason to have it translated. I think so. But the technical problems are too large _now_. I have one idea: make another po (or other) file and move traslations there. But it requires extra code for switching between two catalogs. Translators will first translate gimp-std-plugins and then, when they have enough effort, can translate gimp-pdb. hmm... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
