On Wed, Nov 09, 2005 at 03:11:25PM +0100, Georg Baum wrote: > Jean-Marc Lasgouttes wrote: > > > All of this is doable IMO. But a major problem I see is that > > translators may need to use different shortcuts for a string in > > different frontends. How do we make that possible? > > Fictive example: The string "&Print" needs the translation "&Drucken" in > xforms and "D&rucken" in qt. > > This string could be duplicated as follows, using the machinery for ambigous > translations: > > original translation > &Print[[xforms]] &Drucken > &Print[[qt]] D&rucken >
Why? Do these identical strings _need_ different shortcuts, or was it merely convenient at the time? It doesn't look like a big problem though. In cases where different shortcut is needed, simply write "&Drucken" in the one case and "D&rucken" in the other case. Then the two strings don't get merged, but at least we can use the same syntax while translating. That would probably merge 95% and ease the burden. When doing the Norwegian translation I came up on heaps of these strings that only differ in the shortcut - as almost everything seems to have a shortcut these days. (Never figured out why - can all the shortcuts in a form actually be used - if so, how? You're usually in some text entry field, so pressing a letter enters it into the field. Quite unlike menus were keyboard shortcuts is nice for the mouse-haters.) > The xforms sources would contain &Print[[xforms]], and the qt sources would > contain &Print[[qt]]. Of course we have a duplicated string to translate, > but this is not worse than the current state. The .po utilities seems to merge the duplicates, as long as they are true duplicates. So they are translated only once, except for the very rare cases when you have to split them. Helge Hafting
