> >>>>> Hello List,
> >>>>>
> >>>>> I need your help.
> >>>>>
> >>>>> I inserted the following part into "$this->applications = array"
in
> >> the
> >>>>> registry.local.php file.
> >>>>>
> >>>>> ------------
> >>>>> 'forwards' => array(
> >>>>> 'url' => '/ingo/basic.php?page=forward',
> >>>>> 'name' => _("Forward"),
> >>>>> 'status' => 'active',
> >>>>> 'menu_parent' => 'imp',
> >>>>> 'fileroot' => '/tmp'
> >>>>> ),
> >>>>>
> >>>>> 'vacations' => array(
> >>>>> 'url' => '/ingo/basic.php?page=vacation',
> >>>>> 'name' => _("Vacation"),
> >>>>> 'status' => 'active',
> >>>>> 'menu_parent' => 'imp',
> >>>>> 'fileroot' => '/tmp'
> >>>>> ),
> >>>>> ------------
> >>>>>
> >>>>> I don't know if this is the correct way, to get the links to ingo
> >>>>> forward and vacation into the top bar.
> >>>>>
> >>>>> At least partially it is working, what I have done. The links are
> >>>>> visible, and they point to the right target.
> >>>>> Sadly the translation of the "name" isn't constantly working. It
is
> >> only
> >>>>
> >>>>> translated, if I'm located on an ingo page. If I'm unter kronolith
> >> and
> >>>>> want to go to Ingo/Forward, the link name of Forward isn't
> >> translated.
> >>>>>
> >>>>> How can I solve that?
> >>>>
> >>>> I'm not 100% sure how gettext works, but that's probably because
these
> >>>> translated strings only exist in Ingo PO/MO module.
> >>> That sound's plausible.
> >>>>
> >>>> If you change the location of translation strings, e.g. move them
from
> >>>> Ingo to Base module, you need to update translation files
accordingly.
> >>>>
> >>> For updating the translation files there is the "horde-translation"
> >>> script, I guess.
> >>> So I shortly went though the documentation and found
> >>> "horde-translation update -l ll".
> >>> The script was executed with no error an for some modules it says
> >> "updated".
> >>> Then I executed "horde-translation make -l ll", but the shown
results
> >>> are empty.
> >>
> >> Did you specify your locale in place of "ll" flag or did you run the
> >> commands exactly as you wrote?
> > Yes, I ran the commands exactly as I wrote.
> >
> > Meanwhile I'm one step further, I have tried the commands for only
> > one module and language.
> >
> > horde-translation update -m horde -l de
> > horde-translation make -m horde -l de
> >
> > But no changes were found and translation isn't working.
> > After checking the horde.po file, I realized that only the
> > config/registry.php is mentioned.
> >
> > My changes in config/registry.local.php are ignored by the
> > translation script.
> > After inserting my changes into config/registry.php and repeating
> > the commands.
> > The changes were recognized and automatically translated for that
> > module and language.
> >
> > So my next question are.
> > Is there option for the horde-translation script to make it search
> > the "config/registry.local.php" file?
>
> No.
>
> > What happens to the translation after an update?
>
> What do you mean?
I think he means what happens to the translation after Horde update -
translations are updated obviously, so your changes will be lost.
I don't know gettext enough but it should be possible to have a separate
.mo file in the same category as horde.mo is and then load it in your
.local.php files.
For example:
LC_MESSAGES/
horde.mo
local.mo
Then in local.php file use something like this:
'name' => dgettext('local', "Your String");
Of course you have to use your own gettext tools to create such .po/.mo
file. There are dozen of them on the web.
That's probably an overkill for two strings though.
> >>> Have I done something wrong, or do I really have to edit every *.po
file
> >>
> >>> for every language as it is described in the documentation under
"2.1.5
> >>> Extending existent translations" ?
> >>
> >> Yes, in order for particular translations to work you should edit
> >> corresponding po files. I'm not sure you need to do it for all
modules
> >> though. Just start from the base "horde" module and see if that
helps.
> >>
> >> If you need only 1 language just use static strings.
> >>
> >>>> Alternatively you could just use static strings.
> >>>>
> >>> Static strings aren't really an option, because the translation
> >>> information should be available and I only have to find out how to
get
> >>> it working.
--
Vilius