Please upgrade here. These earlier versions are no longer being updated and have security issues.

Localization for the Signature-Plugin?

This discussion is related to the Signatures addon.
rkneschkerkneschke New
edited April 2012 in Vanilla 2.0 - 2.8

Hello,

would it be possible to make a .ini-file or something similar so it is easier to change the language of the text in the plugin that the forum users see?

I am not too familiar with PHP and are arfraid to break something if I change the .php files...

Thanks in advance, Robert

Best Answer

  • x00x00 MVP
    edited April 2012 Accepted Answer

    The first thing to try is the

    $Definition['The actual English text']

    Sort index names tend to be used in long pieces of text or where there could be ambiguity. Form element labels tend to be locale friendly, anything with T('some text') is locale friendly.

    I think locales are best managed by creating a proper locale rather then in the plugin. That way they won't be overwritten.

    There is already a locale system no need for another.

    grep is your friend.

Answers

  • UnderDogUnderDog Moderator

    Do you mean that the text in the Signatures Plugin is hard-coded in english? No language constants which point to a language definition file?

    That's a bug.

  • The plugin seems to consist of a .css file and 4 .php files (called
    class.signatures.plugin.php
    settings.php
    signature.php
    usersig.php)

    I could change the .php files manually but as I said I am afraid to change too much because I am worried I might break something.

    But so far I only found a few plugins that allowed easy language change (mostly for the front-end, almost never for the backend)

    Does it answer your question?

    Thanks, Robert

  • peregrineperegrine MVP
    edited April 2012

    can you give some examples of plugins that had easy language change and maybe some people (me) could get some tips to incorporate. If any one wants a language change for my plugins, let me know, but I wonder who is using any of them that require one.

    I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.

  • @peregrine: Okay, some plugins that I know of:
    "AboutMe" comes with a definitions.php in a "locales" folder that can be easily changed, but it contains only a small part of the total language parts (which still confuses me).
    "UserList" has a field in the backend settings that lets you change the frontend name shown (which can be used to change the language as well), but the backend features are still in English, similar is "PM", it lets you change the frontend language shown, but backend not.

    peregrine
  • peregrineperegrine MVP
    edited April 2012

    what do you mean by backend - the settings menu

    I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.

  • UnderDogUnderDog Moderator

    I think R means the entire Admin section. It's all in english and most probably all hard-coded in english. Will be a h*ll of a job to change that into language definitions though.

    peregrine
  • thanks

    I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.

  • @pregrine: Yes, I meant the admin section.

    But I do understand enough English to work with english definitions in the admin section, but it it always a pain to find out WHERE text appears in the frontend and WHERE I need to change what to adapt it to German.

    Wouldn't it be possible to use strings for text that will be shown for the users like (pardon possible mistakes): "echo {text-string1}" and then have a language.ini
    with
    text-string1="Hello"
    text-string2="Enter your data"

    etc.

    This way one only would need to change the details in the language.ini and done.

  • x00x00 MVP
    edited April 2012 Accepted Answer

    The first thing to try is the

    $Definition['The actual English text']

    Sort index names tend to be used in long pieces of text or where there could be ambiguity. Form element labels tend to be locale friendly, anything with T('some text') is locale friendly.

    I think locales are best managed by creating a proper locale rather then in the plugin. That way they won't be overwritten.

    There is already a locale system no need for another.

    grep is your friend.

  • @x00: I have the German locale installed and running but of course the language pieces of additional plugins do not get recognized. I tried out the "Locale Developer" plugin now and will see if that catches the rest of the "not translated" parts...

Sign In or Register to comment.