Hi, thanks for your reply the problem is that, in my Language, there is a big difference between the translation of 'lock' and the translation of 'locked'. This difference makes that the people don't understand if they see a 'lock' where it should be 'locked' (that is, where it should be an adjective, not a noun or verb) my first aproximation (changing values in otrs.ticket_lock_type) was wrong because the values 'lock' and 'unlock' are hardcoded in the Perl modules and I'd have to change ~100 lines of code in several modules. Instead, I've modified Ticket.pm to add a custom field to tickets ($Ticket{Locked} = 'Yes'|'No') and ' Ticket Information' in AgentTicketZoom to show this field (now it looks like "Locked:Yes | No"). I don't like this solution, but it works Juan Clavero Almirón Gestiò d’Identitats, Firma i Custòdia Oficina de Tecnologies, Informació i Comunicacions (OTIC) Servei de Salut de les Illes Balears C/ de les Escoles, s/n - 07181 Bendinat - Mallorca Telf. +34 971.42.65.30 -----Mensaje original----- De: Nils Leideck [mailto:nils.leideck@leidex.net] Enviado el: martes, 08 de noviembre de 2011 16:57 Para: User questions and discussions about OTRS. Asunto: Re: [otrs] Lock/Unlock vs Locked/Unlocked Hi Juan, I recommend to just add your own language translation and translate “lock” and “unlock” to whatever you need. Could be handy to translate it to “in progress” and “free” .... or whatever your procedure likes :-) Look here for some more details: http://doc.otrs.org/developer/3.0/en/html/contributing.html#translate On 08.11.2011, at 16:37, Juan Manuel Clavero Almirón wrote:

as I’m customizing OTRS to fit my company, I’ve hit a problem in the use of Lock/Unlock: this words may be noun or verb, but they cannot be adjectives. But they are used as such in the Ticket Information section. Maybe this is not a big difference in German or in English, but in Spanish it’s definitely strange, wrong. I’ve manually changed this lock states in MySQL (otrs.ticket_lock_type), but it starts failing because you can use the method ‘LockLookup’ with ‘LockID’ (which would be the ID in the MySQL table) or with ‘Lock’ (by the name).

Here are my questions: a) Is possible to force ‘LockLookup’ only accepting ‘LockID’? Why does OTRS need to know the name of the lock states to find them? b) Is possible to make the distinction between Lock/Unlock and Locked/Unlocked in another way?

-- Cheers, Nils http://webint.cryptonode.de / a Fractal project

Dear both, @ Juan, we know this is a notation issue and i hope that this will be “fixed” very soon. Please be so kind and open a bug report on bugs.otrs.org or just update an bug that I found which seems to be related to this issue: http://bugs.otrs.org/show_bug.cgi?id=6441 @ Carlos, changing the xx_Custom.pm doesn’t solve the problem of the differences between "to lock” and "the lock”. If you e.g. translate “lock” to “take over”, you will have locked tickets displayed as “take over” tickets, which is also with no sense ;-)) On 09.11.2011, at 13:28, Carlos Andrés Gallego Arboleda wrote:

Did you try change the es_Custom.pm that's work's for me

El nov 9, 2011 7:10 a.m., "Juan Manuel Clavero Almirón" escribió: Hi, thanks for your reply

the problem is that, in my Language, there is a big difference between the translation of 'lock' and the translation of 'locked'. This difference makes that the people don't understand if they see a 'lock' where it should be 'locked' (that is, where it should be an adjective, not a noun or verb)

my first aproximation (changing values in otrs.ticket_lock_type) was wrong because the values 'lock' and 'unlock' are hardcoded in the Perl modules and I'd have to change ~100 lines of code in several modules.

Instead, I've modified Ticket.pm to add a custom field to tickets ($Ticket{Locked} = 'Yes'|'No') and ' Ticket Information' in AgentTicketZoom to show this field (now it looks like "Locked:Yes | No"). I don't like this solution, but it works

Juan Clavero Almirón

-- Cheers, Nils http://webint.cryptonode.de / a Fractal project