How can I change a CouchDB view collation to sort skandinavian letters (åäö) after z?
You can't configure it unfortunately. The collation for CouchDB is implemented via the ICU library which does have the facility to provide alternative collations, both from a locale DB and totally custom rules.
Unfortunately CouchDB does not expose any of that, its ucol_open call has a hardcoded "" value for the locale.
As it stands, in order to customize this for your locale, you would need to recompile CouchDB passing a value for that locale parameter to ucol_open, more info on the format etc of that is available here.
Related
I am using geoserver 2.20.0 to provide wms.
I use the i18n internationalization for the wms configuration. I have also set an i18n entry with empty language for each configurable field, acting as the default translation.
Geoserver uses the default values of the title and abstract of the service, when no language parameter is used in the request.
But when I send a getcapabilities request with invalid or not supported language parameter, instead of getting the default values of title and abstract, I get an exception.
Is there a way to fix this and make geoserver respond with the default values?
I have a modx site that outputs some dates on a bunch of different pages in both English and French - it worked fine but now the owner is reporting French dates showing 'funny characters'
The database, modx and page are all using UTF8 encoding, the date value (publishedon) is stored as a unix time in the data base and is called like this:
[[+publishedon:strtotime:date=`%B %e, %Y`]]
Which from my understanding is just using the php strtotime function, however on the French pages the date shows up as:
d�cembre 18, 2018
So the Locale functions are working but not the character set, NOW immediately fog that date is some copy from the database:
"Le 18 décembre"
Using the correct characters, so we can see the encoding for the page is correct, but the function appears to be not using the correct character encoding!?
Modx has not been updated.
Does anyone know what might be going on here and how to set the corect encoding for the output?
UPDATED INFORMATION:
there are 2 web contexts defined, English and French. Each has a locale defines as en_EN & fr_FR respectively
the modx_charset is UTF-8 set in the system settings
use_multibyte is enabled in the system settings an mbstring is installed & enabled on the server.
modx version is 2.6.5
Use an utf8 capable locale MODX system setting, like fr_FR.utf8 or similar.
You have to look before, which locales are available on your host.
it worked fine but now the owner is reporting French dates showing 'funny characters'
It's interesting what happened and became the cause..maybe some server updates take place? Sometimes hoster makes an indelible contribution :)
What encoding do you have now in php.ini file?
Additionally what MODX version do you use?
Also please let know what stored for next modx system settings(directly or redefined by context settings):
locale, modx_charset, use_multibyte
Br,
Anton
I referred this page as described below and could get some values.
$ curl -v "https://sonarcloud.io/api/measures/component?metricKeys=violations&component=key" | jq
But how can I get these values with language filter?
Querying project-level metrics by language is not possible. As you can see on the description of the /api/measures/component web service, there's no language parameter.
If you are interested in issues in particular (I'm asking because I see that you are trying to query the violations metric), then you should be using the /api/issues/search web service for which you have a language parameter.
Thank you for a comment & answer! It was self resolved.
I tried sonar-scanner with language options like -Dsonar.language=c and after that, accessed the Web API. By doing so, I can get the value of C code.
I'm developing an API Server in Go and the server (at the moment) handles all translations for clients. When an API client fetches particular data it also asks for the translations that are available for the given section.
Ideally I want to have the following folder structure:
/messages
/home.en
/home.fr
/home.sv
/news.en
/news.fr
/news.sv
Where news and home are distinct modules.
Now the question I have for Revel is is it possible to fetch ALL language strings for a given module and given locale? For example pull all home strings for en-US.
EDIT:
I would like the output (something I can return to the client) a key:value string of translations.
Any guidance would be appreciated.
It seems to me that revel uses messaged based translation (just like gettext does), so you need
the original string to get the translation. These strings are stored in Config objects,
which are themselves stored in messages of i18n.go, sorted by language.
As you can see, this mapping is not exported, so you can't access it. The best way
to fix this is to write a function for what you want (getting the config by supplying a language)
or exporting one of the existing functions and create a pull request for revel.
You may workaround this by copying the code of loadMessageFile or by forking your version
of revel and exporting loadMessageFile or parseMessagesFile. This also is a great opportunity
to create a pull request.
Note that the localizations are stored in a INI file format parsed by robfig/config,
so manually parsing is also an option (although not recommended).
I have defined my routing using the special _locale parameter. When a route is matched by the router, the locale is correctly set in my user session and I can see the correct locale being used in the profiler.
$this->get('session')->getLocale(); // Return the correct locale
The problem is that the i18n translator is always using the default locale defined in my parameters.yml file instead of using the locale set in the session.
Is there something i'm missing ? Do I have to manually pass the session locale to the translator ?
I'm using Symfony 2.0.9.
According to this link: Translations configuration, "The locale used in translations is the one stored in the user session.". If it's not the case for you, I guess you changed something in your configuration?
By the way, the locale will be stored in the request and not in the session anymore in 2.1: https://github.com/symfony/symfony/commit/74bc699b270122b70b1de6ece47c726f5df8bd41