CLDR right unicode is giving me the wrong symbol - unicode

I'm currently trying to change the currency symbol for the south korean won in my prestashop 1.7.3.4 installation to the hangeul version, that just reads "won" (원). Which is more commonly used than ₩. Prestashop uses unicode for these. The default value in
main--ko-KR-currencies is:
"KRW":{"displayName":"\ub300\ud55c\ubbfc\uad6d \uc6d0","displayName-count-other":"\ub300\ud55c\ubbfc\uad6d \uc6d0","symbol":"\u20a9","symbol-alt-narrow":"\u20a9"}
and in main--ko-KR-numbers is:
{"main":{"ko-KR":{"identity":{"version":{"_cldrVersion":"26","_number":"$Revision: 10669 $"},"generation":{"_date":"$Date: 2014-07-23 16:10:33 -0500 (Wed, 23 Jul 2014) $"},"language":"ko","territory":"KR"},"numbers":{"defaultNumberingSystem":"latn","otherNumberingSystems":{"native":"latn"},"minimumGroupingDigits":"1","symbols-numberSystem-latn":{"decimal":".","group":",","list":";","percentSign":"%","plusSign":"+","minusSign":"-","exponential":"E","superscriptingExponent":"\u00d7","perMille":"\u2030","infinity":"\u221e","nan":"NaN","timeSeparator":":"},"decimalFormats-numberSystem-latn":{"standard":"#,##0.###","long":{"decimalFormat":{"1000-count-other":"0000","10000-count-other":"0\ub9cc","100000-count-other":"00\ub9cc","1000000-count-other":"000\ub9cc","10000000-count-other":"0000\ub9cc","100000000-count-other":"0\uc5b5","1000000000-count-other":"00\uc5b5","10000000000-count-other":"000\uc5b5","100000000000-count-other":"0000\uc5b5","1000000000000-count-other":"0\uc870","10000000000000-count-other":"00\uc870","100000000000000-count-other":"000\uc870"}},"short":{"decimalFormat":{"1000-count-other":"0000","10000-count-other":"0\ub9cc","100000-count-other":"00\ub9cc","1000000-count-other":"000\ub9cc","10000000-count-other":"0000\ub9cc","100000000-count-other":"0\uc5b5","1000000000-count-other":"00\uc5b5","10000000000-count-other":"000\uc5b5","100000000000-count-other":"0000\uc5b5","1000000000000-count-other":"0\uc870","10000000000000-count-other":"00\uc870","100000000000000-count-other":"000\uc870"}}},"scientificFormats-numberSystem-latn":{"standard":"#E0"},"percentFormats-numberSystem-latn":{"standard":"#,##0%"},"currencyFormats-numberSystem-latn":{"currencySpacing":{"beforeCurrency":{"currencyMatch":"[:^S:]","surroundingMatch":"[:digit:]","insertBetween":"\u00a0"},"afterCurrency":{"currencyMatch":"[:^S:]","surroundingMatch":"[:digit:]","insertBetween":"\u00a0"}},"accounting":"\u00a4#,##0.00;(\u00a4#,##0.00)","standard":"#,##0.00\u00a4","unitPattern-count-other":"{0} {1}"},"miscPatterns-numberSystem-latn":{"atLeast":"{0}+","range":"{0}-{1}"}}}}}
With emphasize on:
"percentFormats-numberSystem-latn":{"standard":"#,##0%"},"currencyFormats-numberSystem-latn":{"currencySpacing":{"beforeCurrency":{"currencyMatch":"[:^S:]","surroundingMatch":"[:digit:]","insertBetween":"\u00a0"},"afterCurrency":{"currencyMatch":"[:^S:]","surroundingMatch":"[:digit:]","insertBetween":"\u00a0"}},"accounting":"\u00a4#,##0.00;(\u00a4#,##0.00)","standard":"#,##0.00\u00a4","unitPattern-count-other":"{0} {1}"},"miscPatterns-numberSystem-latn":{"atLeast":"{0}+","range":"{0}-{1}"}}}}}
According to my research:
u20A9 = ₩
uc6d0 = 원
But as we can see, the main--ko-KR-currencies file alreads uses uc6d0 and it gets displayed as ₩.

In the first line, try changing
"symbol":"\u20a9","symbol-alt-narrow":"\u20a9"
to
"symbol":"\uc6d0","symbol-alt-narrow":"\uc6d0"

Related

Is the data behind the current osmnames.org built using latest OSM data and latest code in github.com/OSMNames/OSMNames?

Performing fresh OSMNames extracts using latest codeset from https://github.com/OSMNames/OSMNames
often omits a level in the country/state/county/city hierarchy.
For example:
Vale of Glamorgan (in Wales, UK) is type:state_district and is defined in OSM (OSM id 103776, AdminLevel 6) as an admin boundary made up of ways and relations.
https://github.com/OSMNames/OSMNames/releases/download/v2.1.1/planet-latest_geonames.tsv.gz 2019 tsv file has Dinas Powys (OSM id 8219427, AdminLevel 10) as a town within Vale of Glamorgan.
As does the online https://osmnames.org/#q=Dinas%20Powys%2C
But an OSMNames build from latest 2021 data (https://download.geofabrik.de/europe/great-britain/wales-latest.osm.pbf) omits Vale of Glamorgan from Dinas Powys info.
If we try using older data in a Wales OSM history file - https://osm-internal.download.geofabrik.de/europe/great-britain/wales-internal.osh.pbf
Using osmium-tool to extract a data snapshot which should match the 2019 date of https://github.com/OSMNames/OSMNames/releases/download/v2.1.1/planet-latest_geonames.tsv.gz
(osmium time-filter wales-internal.osh.pbf 2019-05-13T00:00:00Z -o wales_2019.osm.pbf)
When we run the OSMNames build against this filtered file which should equal the May 2019 data, it still doesn't have Dinas Powys in Vale of Glamorgan.
So we appear to have a disparity between what was achieved in https://github.com/OSMNames/OSMNames/releases/download/v2.1.1/planet-latest_geonames.tsv.gz (generated in May 2019) and what we can reproduce using the https://github.com/OSMNames/OSMNames code
set.
Apparent conclusions:
The current online https://osmnames.org/#q=Dinas%20Powys%2C is
using OSMNames data from a few years ago, laid over current maptiles.
If so, the website should make this clear.
The https://github.com/OSMNames/OSMNames/releases/download/v2.1.1/planet-latest_geonames.tsv.gz was not built using unaltered code from the git repository.
The github site, states:
"If you are a user and have questions, we're sorry that we can't give individual support. Pls. ask support questions over at Stack Overflow", but there doesn't appear to be much activity.
Can anyone confirm my conclusions, or point me to something more recent?
As another example, the UK village of Fulletby:
In the 2019 tsv file, its display_name is "Fulletby, East Lindsey, Lincolnshire, East Midlands, England, United Kingdom".
But using latest codeset and OSM data gives a display_name of only "Fulletby, Lincolnshire, England, United Kingdom".

Android-AppWarp Unity SDK: BAD_REQUEST/CONNECTION_ERROR when calling WarpClient.GetInstance().Connect()

I'm running into the issues since today. The way I was keeping the user name unique was creating it as ${FACEBOOK_FIRST_NAME}_${FACEBOOK_ID} and WarpClient.GetInstance().Connect(${FACEBOOK_FIRST_NAME}_${FACEBOOK_ID}) worked just fine till now.
Today it stopped working, and after trial and error it seems that the username length is limited to 21 characters now. 22 characters user name causes CONNECTION_ERROR, 23 and more - BAD_REQUEST.
Is it a new restriction introduced, and if it is, what is the best way to maintain unique but readable user names based on users FB credentials?
10x
There are restrictions on the username string.
The length should be less than 25 and the following characters are not allowed
, ; \ /
See the API reference.
http://appwarp.shephertz.com/game-development-center/csharp-api-reference/#connect
Hope it helps.

SSRS report parameter.label showing parameter.value

I have a SSRS report, in my report I have a dataset which has an ID and NAME field, then I created a parameter and set its value to ID from dataset and Label to NAME of dataset. I can see the label when I preview report and select it, but I am also showing the selected parameter on report for this I am using expression :
=Parameters!P_TargetBrand.Label
But when report runs it is showing parameter VALUE instead of Label.
My SQL version is :
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2550.0 (X64) Jun 11 2012 16:41:53 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)
Case when your parameter is Single Value :
=Parameters!<ParameterName>.Label
Case when your parameter is Multi Values :
=Parameters!<ParameterName>.Label(0)
OR
=Join(Parameters!<MultivalueParameterName>.Label,", ")
For Additional information try here.
I came across this problem and as far as I can tell it is a bug unsupported feature.
On this page - http://technet.microsoft.com/en-us/library/gg731894.aspx
They have two issues that are related to our problem:
"The Label reference does not display properly. The Value property is set to the Parameters!MyParm.Value parameter."
Addtl. Info: "The parameter must be explicitly bound to data using a dataset in the Visual Studio Tools for Microsoft Dynamics AX report model."
and
"The parameter is explicitly bound to datasets with two columns, label and value. The value displays properly. The Label reference displays properly everywhere except in the client."
Addtl. Info: "The report viewer control does not support the ability to specify report parameter labels, only values."
In my case we're not using a bound dataset. Just our own backend and adding the parameter values to the reporting view object. So we're SOL. Really lame that we have to get a label/value pair. Then hit the database again to get the label for the selected value since we don't have direct access to the label.
I would love to be proven wrong.

Word 2013 Formula: Why does not the TRUE function work?

I'm trying to use the TRUE function in a Word table, but I only get a syntax error I can't interpret. Two similar functions work just fine. What could be wrong?
My simple table with 2 columns and 3 rows has the following functions specified:
function return
=OR(1=1;1=5) 1
=TRUE(1=1) !Syntax Error, (
=NOT(1=1) 0
Formula reference:
http://office.microsoft.com/en-us/word-help/use-a-formula-in-a-word-table-HA102329800.aspx#_Toc281293376
First of all, the documentation you link to is for Word 2007 and 2010 and not for 2013. However, I agree with you - this looks like a documentation bug.
On this documentation page I found the documented behavior of the TRUE function in Word 2007, 2010, and 2013 to be defined as: always return 1 - explaining why you get the syntax error.
So ye, the two pages definitely contradicts each other, but I would go the the documentation page I provided, since it covers Word 2013 as well (which appears to be the version you are working with).
It seems as TRUE dos not take any arguments. It only returns a 1, as FALSE only returns a 0.
function return
=TRUE 1
=FALSE 0
So the documentation is wrong, I suppose.

Bing search API - How to localize results?

How can I use Slovenian search results by default? Our server has German IP and Bing API automatically shows German results first. I have already tried some of the parameters as described in documentation and none of them worked so far.
Thanks
Have you tried to set the Market option?
According to this example page, you should try something like this (note &Market=sl-SL argument):
http://api.bing.net/json.aspx?AppId=your_AppId&Query=your_query&Sources=Web&Version=2.0&Market=sl-SL&Options=EnableHighlighting&Web.Count=10&Web.Offset=0&JsonType=callback&JsonCallback=SearchCompleted
First off, Slovenia is currently not a Bing Market or Country.
There are 2 mutually exclusive options to configure a localization.
Since Slovenia is not yet supported, you might want to use 2. to combine results from relevant markets.
Using mkt and setLang
The values for mkt - Market Code are here.
The query value setLang, "The language to use for user interface strings. Specify the language using the ISO 639-1 2-letter language code. For example, the language code for English is EN. The default is EN (English)."
https://api.cognitive.microsoft.com/bing/v7.0/search?q=microsoft&mkt=en-US&setLang=EN
Using cc and Accept-Language
The values for cc - Country Code are here.
This allows you to specify multiple languages via the header value Accept-Language.
https://api.cognitive.microsoft.com/bing/v7.0/search?q=microsoft&cc=US
True, setting the Accept-Language does very little for the actual
result. If you want to localize outside of a Bing market country, you'll like have to include a translation service.
Values for the Market parameter