Open jorgesumle opened 5 years ago
Good news, this is already implemented!
I have gotten this kind of request many times, for things like language, specific form fields, theme, etc, so the settings were made adjustable from the frontend. It works in pretty much the way you describe, but it's abstracted a bit to make it easy to use, you get to set the setting values as a normal JavaScript object without having to worry about URI component encoding the query values.
To adjust settings from the frontend you need to use the loader script.
So instead of:
<script type="text/javascript" src="/hashover/comments.php"></script>
You use:
<script type="text/javascript" src="/hashover/loader.php"></script>
And than you need to instantiate an instance manually with the language setting.
Like so:
<script type="text/javascript">
var hashover = new HashOver ('hashover', {
settings: {
language: 'de_DE'
}
});
</script>
This example sets the language to German, you could use eo_EO
instead (assuming an Esperanto locale exists in /hashover/backend/locales/eo-eo.php
). Or you can make this a variable containing a string value from something like a dropdown menu, a URL query or part of the path, a cookie, a database, or anything else that's available to the JavaScript frontend.
See the "Technical" section of the documentation for more information.
I'm sorry for wasting your time by not reading the documentation. The implementation seems reasonable.
you could use
eo_EO
instead
Regarding the example about Esperanto, because it is an international language with yet no regional variations, as far as I know, the translation code should be just eo
. The ISO 3166-1 country code EO
is unassigned.
@jacobwb, I successfully applied the code to translate the comment system. However, I'm using the count API as well, and the text added by calling api/count-link.php
is not translated. What is the default method to override the language setting if you are just calling that script?
I'm sorry for wasting your time by not reading the documentation. The implementation seems reasonable.
Not a problem.
you could use eo_EO instead
Regarding the example about Esperanto, because it is an international language with yet no regional variations, as far as I know, the translation code should be just eo. The ISO 3166-1 country code EO is unassigned.
The eo_EO
form is used to help HashOver detect the system language automatically, as this is the form locale codes take on GNU/Linux systems. Many languages that don't have regional variations use this form, like lt_LT
(Lithuanian), pl_PL
(Polish), tr_TR
(Turkish) and there are language codes like ja_JP
(Japanese) that state which country the language is from despite it not having regional variations (to my knowledge).
If I understand correctly, Esperanto is a language that isn't supposed to need regional variations, it has also never been the official language of any country, which makes it quite unique. However, despite this fact, the Esperanto locale code is often just eo
or eo_EO
or eo_US
and sometimes it's eo_XX
on GNU/Linux. I don't know what the difference is between the eo
locale and the eo_US
variant if any. With such eccentricities HashOver is likely to fail to detect Esperanto automatically on some systems.
Locale files named with only the first part of the code (eo.php) used to be supported, but it was removed to simplify the code and to remove ambiguity about what language and region the locale is for. So the current naming scheme treats Esperanto the same way as other languages without regional variations. With that said, what should be supported is the ability to use only the first part of the locale as the language setting. And that is what I have now implemented, so you can now use 'eo'
as the language setting and it will map to the "eo-eo.php" file, likewise 'de'
will map to "de-de.php", etc.
Let me know if I'm missing something in this approach that you think is important.
I successfully applied the code to translate the comment system. However, I'm using the count API as well, and the text added by calling api/count-link.php is not translated. What is the default method to override the language setting if you are just calling that script?
Thanks for mentioning this problem. There is no way to change the language in the APIs currently. However, the APIs share code with HashOver itself, so it can be added. I will look into adding support for passing settings to the APIs from their frontends soon.
I have a website with translations and I would like the Hashover interface for translation to be in language of the translated text. One simple solution is to specify an argument to the PHP script like
hashover.php?language=eo
that overrides the default configuration. Would it be feasible and reasonable to implement this method to allow users override default settings?