XOF and XAF currencies doesn't have the same symbol
XOF and XAF currencies are both used in Africa, have the same value and share a common history.
They also share the same name, which is "CFA Franc" or "Franc CFA" in the local language, which give "FCFA" as currency symbol.
See the wikipedia page about the two currencies:
You can find in local website that the currency symbol is "FCFA" in both region, for example:
But, in CLDR data last release, you can found that both currencies do not share the same symbol. XAF symbol is FCFA, but XOF symbol is CFA.
Extract of `af.xml` file:
I don't know if the topic have already been discuss, but I think this discrepancy should not exists (and it cost us harm to deploy a service in Ivory Coast).
I hope you can help us on this !
Again, thanks for your work on the subject, I appreciate it!
since the visual representation (FCFA and F<WJ>CFA) would be ambiguous (and part of the design is to be able to map from the visual representation back to the currency code)
I don’t understand this point. Is it a technical limitation too?
If it’s an “it always been like that“ limitation I think it’s wrong that it impacts 130million peoples.
130million peoples it’s four times Canada, one-third of the US, one-fourth of Europe.
If this limitation is a “convenience“ for developers of CLDR data, I hope this “convenience“has been weighed against the “inconvenience“ for these 130millions peoples.
That been said, `U+202F` is OK for me!
it can be in the 27 January release.
+1 with on both points.
I prefer U+202F too for a nicer visual representation with letters closer to each other.
Thank you !
Thanks for your answer .
Here is my feedback:
Having FCFA without space is not only what “we” are seeking: it’s the real currency name, in the real world.
F<narrow no-break space>CFA is incorrect, but still better than CFA, so I’m +1 for this change.
Thanks again for following this up.
Unfortunately, the “F<WJ>CFA” proposal is not an option, since the <WJ> is zero-width, therefore invisible and thus visually ambiguous. (I understand your comments about the specification, but I don’t think it’s likely to change.)
That leaves the “F<space>CFA” option, but discussion in today’s meeting indicates that the <space> could be a thin space (since several types of spaces are treated as equivalent).
So, the proposal is to use “F<space>CFA” where <space> is
U+202F Narrow No-Break Space (preferred)
U+2009 Thin Space (second choice)
I understand that this is not exactly what you are seeking (because there will still be a small gap between “F” and “CFA”), however, it seems as though this is the best solution available.
Data freeze for v39 is 27 Jan (two weeks from today), so it would be helpful to have your comments soon, Thanks!
Hi , and ,
Happy new year guys!
+1 with the proposed solution of using “F<WJ>CFA”. It looks to be the best solution for now.
Hopefully this will be addressed in CLDR release 39
do you know which other CLDR maintainer can be added in the loop to help fixing this issue so it’s effectively included in CLDR 39?