[Kst] [Bug 145477] New: Non-translatable strings due to string composition

[Christian Mueller]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145477         
           Summary: Non-translatable strings due to string composition
           Product: kst
           Version: unspecified
          Platform: Debian testing
        OS/Version: Linux
            Status: NEW
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: kst kde org
        ReportedBy: cmueller gmx de


Version:            (using KDE KDE 3.5.6)
Installed from:    Debian testing/unstable Packages
OS:                Linux

Working on the GUI translations of kst 1.4 I identified some problems with the i18n. 
They stem from the fact that in some places strings are created by replacing 
arguments with other strings. 

The dynamically created string is passed to the i18n function at runtime 
but the message ID extraction that works on the static code has never 
gotten to see any of the composed strings so they cannot be translated.

The examples I found: 

1.)  Please see src/libkstapp/ksteditviewobjectdialog_i.cpp:

void KstEditViewObjectDialogI::showEditViewObjectDialog(KstViewObjectPtr viewObject, KstTopLevelViewPtr top) {
  _viewObject = viewObject;
  if (_viewObject) {
    _viewObject->setDialogLock(true);
  }
  _top = top;
  updateWidgets();
  if (_viewObject) {
    setCaption(i18n("Edit %1").arg(_viewObject->type()));
  }
  _apply->setEnabled(false);
  show();
  raise();
}


And src/libkstapp/kstdatadialog.ui.h:    

setCaption(i18n("New %1").arg(objectName()));


These setCaption calls have two problems: 

First, the results of the calls to type() and objectName() 
are not translated, and second, even if they were, 
this construction kit for strings does not work for all languages / all cases. 
The translation of "New" and "Edit" may depend on the actual second term 
(e.g. its grammatical gender).  

For example: 
"New Equation" should be translated as "Neue Gleichung", 
but "New Plot" should be "Neuer Plot", with an added "r" due to the 
grammatical gender of "Plot".  

Even if I try to circumvent the grammatical problem by chosing a neutral construct
(which may not even be possible in all languages / all cases)
I end up with a mixture of German and English, e.g. "Neu: Equation" 
That's because "Equation" is not translated.

This string appears quite prominently in the window title of the 
"New equation" dialog.


One solution I could think of would be to list all possible string 
combinations as dummy strings so that the message ID extraction gets to see them.  
That would solve both issues, I guess.


(I had talked to George Staikos about this issue but it was already too late for 1.4. 
George suggested I file this as a bug to be fixed later.)