Language Translation Issue

[Gunjan]

Hi,

I want to translate all states in German after changing default language to 'de'. I created a new file 'de_Custom.pm' and added the German translation in that file but it is not working. Please help me!

Thanks & Regards,
Gunjan

[reneeb]

Were did you store that file? Did you restart the webserver? The users' language is set to "de"?

[Gunjan]

Ya I did restart the server and I stored the file in 'Kernel/Language' folder. and user language is also set to de

[reneeb]

Any messages in the log files? Please rename it to de_ZZZCustom.pm and check if it works now. The modules are loaded in alphabetical order, so there might be an other translation file that overrides your changes.

[Gunjan]

Hi,

Sorry for the new thread. but now translation for dynamic fields and for their values is working fine but for ticket types and priorities, it is not translating. Please Help.

Regards,
Gunjan

[reneeb]

Sorry for the new thread.

I've edited my post in the other thread as I misread the title. Sorry.

but now translation for dynamic fields and for their values is working fine but for ticket types and priorities, it is not translating. Please Help.

Ticket types cannot be translated (see other thread). Priorities should work with de_ZZZCustom.pm... Can you post the code from your translation file?

[Gunjan]

Code: Select all

package Kernel::Language::de_ZZZCustom;

use strict;
use warnings;

sub Data {
    my $Self = shift;

    # $$START$$
 $Self->{Translation} = {
            %{$Self->{Translation}},
    	       # own translations
#Priorities
		'1 very low' => '1 sehr niedrig',
		'2 low' => '2 niedrig',
		
#Ticket Types
		
		'Incident' => 'Serviceanfrage',
      };

    # $$STOP$$
}

1;

[reneeb]

That looks ok for the priorities...

[Gunjan]

Hi,

I don't know what the problem is, but I am not able to translate Priorities! I added translation but It is still not showing translation. translation for other fields are working fine but not working for priority! please Help!

Thanks
Gunjan

[reneeb]

The standard priorities are already translated: https://github.com/OTRS/otrs/blob/rel-3 ... de.pm#L662

So, is the translation missing in a customized view?

[Gunjan]

No, Translation of Standard Priorities is missing.

[reneeb]

Please set SysConfig option LanguageDebug to "Yes" and debug the translation process. Please post any log messages. Are your file permissions correct?

[Giulio Soleni]

Hi,
I can report the same issue: after updating to version 4.0.x ( today I update to 4.0.8 ) the translation of names of states and some other properties seems not to be performed as it was for ver 3.3.x

For example in Italian, we should have 'aperto' instead of 'open' for the state, but the translation only applies to the state type and not to the state name.
Please see the two pictures attached.

open state Italian.png

open state EN_US.png

I suspect this is a bug

[RStraub]

There are certain strings that are meant to be "hardcoded" and aren't translatable by default.

If you take a look into AgentTicketPhone.pm you can see the Translation is disabled:
https://github.com/OTRS/otrs/blob/maste ... e.pm#L2334

[crythias]

There are certain strings that are meant to be "hardcoded" and aren't translatable by default.

This is true. Assume that things you can type in are the things that can't be translated for display. The space-time continuum would collapse on itself.

:) What I mean is ... if you think about it, the stuff you type in is what will be translated for display on the web site. But it's got to be consistently translated from the same source word. It doesn't even matter what the source word is. It could be foobar which in German means "Soccer Beer". (No it doesn't... but humor me.)

In order for it to show "Soccer Beer" for those who speak German and "Football Pub" for those who speak Spanish, the same base word (foobar) has to be looked-up to translate. So, you type the base word (sometimes in English) to-be-translated and have the translations look that word up in the web interface, but not the admin interface. That's where you have defined source/base words. But those base words can't be translated at the place you define base words.

[Giulio Soleni]

In order for it to show "Soccer Beer" for those who speak German and "Football Pub" for those who speak Spanish, the same base word (foobar) has to be looked-up to translate. So, you type the base word (sometimes in English) to-be-translated and have the translations look that word up in the web interface, but not the admin interface. That's where you have defined source/base words. But those base words can't be translated at the place you define base words.

...mmh ... I think I understood ... the open state actually is displayed as "aperto" on the customer and agent consoles when preferences are set to Italian, while in the admin console, where it is defined (the previously attached pictures) is the only place where it is not translated.
Yes ... it makes sense

thank you!