Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translation of custom commands/plugins #69

Open
jpfleury opened this issue Apr 18, 2012 · 3 comments
Open

Translation of custom commands/plugins #69

jpfleury opened this issue Apr 18, 2012 · 3 comments
Labels
Milestone

Comments

@jpfleury
Copy link
Contributor

Note: I create this issue to keep track of the discussion Translation of custom commands/plugins started on the old SourceForge forum.

Hi,

I'm writing custom commands to handle the trash. For example, there's a custom command named Mettre à la corbeille. This string is in French and means Move to Trash in English.

If I export this custom command, the label is handled in the file plugin as follows:

cstm_00000000-label=Mettre à la corbeille

I wonder if there's a way to add translation feature, so when it will be shared (for example, on the SpaceFM wiki), the custom command/plugin could already be displayed in the language of the user adding it to SpaceFM.

For example, I could add the following translations:

  • English: Move to Trash
  • Spanish: Mover a la papelera

Translations for other languages could be suggested by users.

Here are some reflections/possibilities about that:

  • There may be multiple label properties:

    cstm_00000000-label-fr=Mettre à la corbeille
    cstm_00000000-label-en=Move to Trash
    cstm_00000000-label-es=Mover a la papelera
    

    or each custom command/plugin may have locale files, so we would have something like:

    file en.po:
    msgid "Mettre à la corbeille"
    msgstr "Move to Trash"
    
    file es.po:
    msgid "Mettre à la corbeille"
    msgstr "Mover a la papelera"
    
  • Multiple translations may be handled in the Change Menu Name dialog or by hand by opening a file in a text editor.

  • Translation handling should be able to manage language declarations of the form language or the form language_COUNTRY. Examples:

    • fr
    • fr_CA
    • fr_FR
    • en
    • en_US
    • ...
@jpfleury
Copy link
Contributor Author

Note: this is a copy of a comment from IgnorantGuru.

I think a good way to handle this for now is to create a separate plugin file for each language:

trash-jpfleury-en.spacefm-plugin.tar.gz
trash-jpfleury-fr.spacefm-plugin.tar.gz
...

And the user can select the appropriate one. (Try to use a unique filename including your name or nickname to help prevent collisions.)

You could do this by making a copy of the original menu item using copy/paste on the design menu. Then translate the copy within spacefm, and export it to an appropriately named plugin file.

To organize them within spacefm, you could put the commands in submenus.

Any script in the command can use the environment variable $LANG to get the user's locale and respond accordingly. That way you would need only one version of the script. Enter this in spacefm's smartbar:

$ echo $LANG

(include the initial $)

I could add a section to the manual on the recommended way to handle this. I'll need to give this some more thought, particularly for the plugins that will eventually be included in spacefm, since the user won't be choosing them based on language. Thanks for pointing it out.

Last edit: IgnorantGuru 2012-02-22

@jpfleury
Copy link
Contributor Author

Note: this is a copy of a comment from jpfleury.

I'll need to give this some more thought, particularly for the plugins that will eventually be included in spacefm, since the user won't be choosing them based on language.

There's also the dialog message of a command whose style is Input.

@IgnorantGuru
Copy link
Owner

There are not many multi-lingual plugins so it appears interest in this is low. I looked it over somewhat and the changes would be a bit involved. Not sure the use it would get would justify the time spent on these changes. So for now the recommendation to create separate plugin files for each language stands. But I'll leave this open and we'll see how the plugin needs change in time, and if I do any rewrites in this area I'll keep it in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants