You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
...
The text was updated successfully, but these errors were encountered:
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.
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.
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.
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:
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:
Translations for other languages could be suggested by users.
Here are some reflections/possibilities about that:
There may be multiple label properties:
or each custom command/plugin may have locale files, so we would have something like:
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
The text was updated successfully, but these errors were encountered: