HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
doesnt work for other langiages
vanillawhisky
New
in Localization
Hello there,
This works fine only in english but doesnt work for other languages. I though have other language Locale (example german).
Can you please suggest me. I can also solve this problem by overwriting all the definition which you have in en-CA.php in my locale.php but I want something to do in the plugins if possible.
hopping to get answer as soon as possible.
Tagged:
0
Comments
Translating the definitions in your own locale file is the preferred way. Congratulations, you did it correctly! :-)
Please don't change anything in the plugins.
If a plugin has the ability to be translated, you can contribute by offering your locale file to the author. Looking at GitHub shows that there is already a German localization available: https://github.com/kasperisager/vanilla-timeago/tree/master/locale
You could use the version from GitHub if you do not want to keep your own translation.
r_J has good advice, if you are using a single language translation.
But a note if you create your own plugin, and want multiple locales (for example with multi-lingual plugin, or are using a plugin that an author will not update or has abandoned and you want the plugin specific definitions.
you need to do 3 steps.
https://vanillaforums.org/get/vf_vi-locale-2016.07.22p1100
look in the definitions.php of the vietnamese locale.
and you will see.
the Locale has the proper name to use. 'Locale' => 'vi', In your plugin folder locale subfolder
create a file called vi.php
Yourplugin/locale/vi.php
the vi.php with the proper vietnamese definitions.
2 enable the locale in the dashboard
3 disable and enable the plugin with the newly added plugin locale (should update the cache).
4 if necessary, delete the ini folders from the cache and ensure you have enabled and resaved the definitions and default locale and re-enable plugin from the dashboard.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
Thank you guys for your comments.
thanks to @River for your points.
I see in github english, german and swedish translated file but if you see in vanilla addons and download it http://vanillaforums.org/addon/timeago-plugin , there are no such files (de.php) for german and even swedish (may be plugin is not updated).
So I cloned and also downloaded (one at a time) and activated. when I cloned, the plugins name is vanilla-timeago but in dashbord shows timeago (ok lets say this doesnt matter). In this case the locale file (de.php) exists but the problem is this plugins works no more. Now it doesnt do anything. moreover i cannot diactivate this plugins (ist it strange )
am I doing something wrong here??????
Many developers keep more recent versions on GitHub, but you should not expect being able to use them without some knowledge. That mustn't be true but it's possible. In this cases, the folders name is the problem. On GitHub it is changed because of whatever reason - only Kasper knows.
Plugins must reside in a folder that is exactly named as the key in the
$PluginInfo[]
array. If that is not the case, you can run into problems when you try to enable/disable them.I would suggest you delete all timeago lines in your
/conf/config.php
, delete the "old" timeago folder, rename vanilla-timeago to timeago and finally delete the *.ini files in /cache.Thanks man , that works fine.
I still have one question. May be I should ask @Kasper but still I am asking here.
Can you make/or plugins so that it insteed of _ '1 day ago' it says _'yesterday at 10:00' with time. Is that possible?
that wouldn't be fuzzy? but this might give you some insights and an additional author to ask.
https://github.com/rmm5t/jquery-timeago/issues/217
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
The plugin changes the time with JavaScript. I'm no fan of this. I do not know if there is a better approach and since that plugin is made by Kasper, I would assume there are good reasons to solve the problem that way.
If I would have to write such a plugin, I would try to change the output right from the beginning. "The beginning", when looking at a single discussion, is in the file /applications/vanilla/views/discussion/discussion.php:
echo anchor(Gdn_Format::date($Discussion->DateInserted, 'html')
.Since it is directly echoed, there is no way to change the output "in the view".
Next step: Gdn_Format. Looking through class formats method date() shows this code:
HEUREKA! So if we provide a function "formatDateCustom", this will be used instead of the default.
The cleanest way to do so is to create an "empty" plugin (it needs to have a plugin info array and a class, but that class doesn't need to have a single method) and attach the replacement function below the class:
After enabling this your dates will be displayed differently (though not useful). You can now copy parts of the original function to your own function and change this copy according to your needs.