The issue is simple, when I try to do auto translate from English to a detected language I got an error, the formula is:
=GOOGLETRANSLATE("Cat"; "en"; "auto")
and the error is something like
Error, Google Translate does not support translation from en to pl-PL.
The problem (I think) is that GOOGLETRANSLATE is supposed to get language as two letter code when default value is language + country code (which is not supported https://support.google.com/docs/answer/3093331?hl=en)
Is it possible to fix that? I would like to translate to user's language (so I want to use "auto" value), no matter what is the language and I assume that if the problem occurs for one language it will happen for different one.
Have you tried to use ; instead of ,.
Example:
=GOOGLETRANSLATE(A1 ; "auto"; "bg")
I have the same issue for Russian. The formula =GOOGLETRANSLATE("Cat"; "en"; "auto") gives the error:
Google Translate does not support translating from en to ru-RU.
This is Google issue, the best way is to report it:
Menu: Help > Report a problem
Here's a workaround:
make a script to detect sheet's locale.
use regex to extract first part of a locale string.
Here's the sample code:
function getLocale()
{
var locale = SpreadsheetApp.getActive().getSpreadsheetLocale(); // pl_PL
return /(.*)_/.exec(locale)[1]; // pl
}
The usage:
=GOOGLETRANSLATE("Cat"; "en"; getLocale())
auto-translate is supported only for these 16 locales:
brazil
germany
mexico
spain
canada (english)
hong kong
philippines
taiwan
china
italy
portugal
united kingdom
france
japan
south korea
united states
see more at: https://stackoverflow.com/a/73767720/5632629
Related
I try this method:
casa -câsa
But that way it excludes the casa without accents too, then the search returns blank.
To the best of my knowledge, Twitter flattens-out all accented latin letters and treats them the same, so...a = á = â = à = ä = ā = ã = å.
One possible way to clean a little bit your search results is to use Twitter's advanced search language operator lang:[xx] in negation -lang:[xx], where [xx] represents the 2 letter ISO language code of the languages which might be using that particular letter (assuming you wish to filter-out from the results).
In your example, the letter Ââ (circumflex) is used by the following languages: Sami, Romanian, Vietnamese, French, Frisian, Portuguese, Turkish, Walloon and Welsh. Assuming you wish to filter-out results from these specific languages, your Twitter search query would look like this:
"casa" -lang:se -lang:ro -lang:vi -lang:fr -lang:fy -lang:pt -lang:tr -lang:wa -lang:cy
try it...
Alternatively, you can use the same lang:[xx] operator to limit Twitter's search results to one specific language (for example - English):
"casa" lang:en
try it...
This might not be a water-tight solution but it can reduce a lot of false positives.
Finally, you should keep in mind that Twitter is not guaranteeing accuracy in their machine-identification of languages.
I am trying to format currencies depending on the currency selected by the user. If no currency is selected, then device's current locale is used for formatting. however, I am having issues:
I am using a number formatter to format the double to currency string.
let formatter = NumberFormatter()
formatter.numberStyle = .currency
formatter.currencySymbol = ""
if currencyCode != nil {
formatter.currencyCode = currencyCode
}
let amount = Double(amt/100) + Double(amt%100)/100
return formatter.string(from: NSNumber(value: amount))
}
The currencyCode is basically the currency the user has selected. However, if say the user selects EURO, the formatting is pretty much the same as for USD, meaning that it is not respecting the currency selected. I know that we cannot possibly create a Locale out of currencyCode since EUR is used in 26 different countries so it's impossible to derive the correct locale.
Also since I am using a format which basically fills the decimals position, then ONES, Tenths and so on and some currencies don't support decimal positions for example, PKR (Pakistani Ruppee) so how can I cater for that?
So my question is how can I format a currency correctly regardless of which device locale is selected.
If my device locale is say USD and I create a EUR list, I would like all payments inside the list to be in EUR format.
So if in USD a price is $3,403.23 in EUR it should be € 3 403,23.
Any advice on how I should go about formatting? Thanks!
In short
The locale settings related to currency are of two kinds:
Currency dependent: these are related to the monetary value and depend only on the currency and remain valid wherever you use that currency. This is only the international ISO code and the number of decimals, as defined by ISO 4217.
Cultural settings: these depend on the usages and practices related to the language and the country of the users and not directly to the currency. Typically, it's the position of the currency code or symbol relatively to the value, as well as the decimal and thousand separators.
Fortunately, Swift makes very well the difference. Here some code, that allows you to adapt the currency dependent settings, without ever touching to the cultural settings that important for the user. I'll also explain why you shouldn't change all the local settings.
The code
Here the demo code, with a couple of representative currencies:
let value: Double = 1345.23
for mycur in ["USD", "TND", "EUR", "JPY" ] {
let myformatter = NumberFormatter()
myformatter.numberStyle = .currencyISOCode
let newLocale = "\(Locale.current.identifier)#currency=\(mycur)" // this is it!
myformatter.locale = Locale(identifier:newLocale)
print ("currency:\(mycur): min:\(myformatter.minimumFractionDigits) max:\(myformatter.maximumFractionDigits)"
print ("result: \(myformatter.string(from: value as NSNumber) ?? "xxx")")
}
For a representative demo, I've used :
the USD and the EUR, which, like most currencies can be divided in 100 sub-units (the cents),
the TND (Tunesian Dinar), which, like a handfull of other dinar-currencies, can be divided in 1000 sub-units (the millims),
the JPY(Japanese Yen), which could in the past be divided into sub-units (the sens) of such a small value that the Japanese government decided not to use them anymore. This is why there are no decimals anymore for JPY amounts.
The results
For the user, will benefit from the principle of least astonishment, and see the decimal and thousand separators and the positioning he/she is used-to.
in my current locale (in my language currency code is to the right, decimals are separated by a comma, and thousands with a hard space) the result will be:
cur:USD: min:2 max:2 result: 1 345,23 USD
cur:TND: min:3 max:3 result: 1 345,230 TND
cur:EUR: min:2 max:2 result: 1 345,23 EUR
cur:JPY: min:0 max:0 result: 1 345 JPY
But if you'd usually work in an English speaking environment, for example in a US culture, you'd get:
cur:USD: min:2 max:2 result: USD 1,345.23
cur:TND: min:3 max:3 result: TND 1,345.230
cur:EUR: min:2 max:2 result: EUR 1,345.23
cur:JPY: min:0 max:0 result: JPY 1,345
How it works:
The trick of the code is to create a new locale, by just changing the currency settings, but leaving intact all other country and language dependent parameters.
let newLocale = "\(Locale.current.identifier)#currency=\(mycur)" // this is it!
myformatter.locale = Locale(identifier:newLocale)
Why you should not fully implement what you wanted
If you would start to adapt the positioning to take the practice of the language of the country the currency is originating from, you might irritate the users who no longer see the currency code where they expect them. Fortunately, it will not create a real confusion.
Example: the EUR is the currency of countries with very different cultures. The rule about positioning of the currency or the currency symbol was therefore defined to be dependent on the language of the text in which the amount appears. Official reference
Now, if you would start to adopt thousand and decimal separators of another language or country because it's the currency's home country, this would create a real confusion, especially for smaller amounts. Moreover, it's not always possible.
Example: In Canada the same currency amount is written with comma decimal separator by French-speaking Canadians, but dot decimal separator by english-speaking Canadians. This clearly shows it's not the currency that determines the separators to use, but the language of the user.
You should therefore be respectful of the user's settings in this regard, and only adapt the currency specific settings.
You can dynamically match Locales to currency codes, since you can create all supported Locales from the availableIdentifiers property of Locale and then you can check their currencyCode property to match the currency code your user input.
extension Locale: CaseIterable {
public static let allCases: [Locale] = availableIdentifiers.map(Locale.init(identifier:))
}
public extension Locale {
init?(currencyCode: String) {
guard let locale = Self.allCases.first(where: { $0.currencyCode == currencyCode }) else { return nil }
self = locale
}
}
Locale(currencyCode: "EUR") // es_EA
Locale(currencyCode:"GBP") // kw_GB
However, as you can see, this can return exotic locales, which might not necessarily give your desired formatting.
I would rather suggest hardcoding the desired Locale for each currency code that your app supports, that way you can be 100% sure the formatting always matches your requirements. You can also mix the two approaches and have hardcoded Locales for the well-known currency codes, but use the dynamic approach for more exotic currency codes that you have no hard requirement over how they should be formatted.
The problem arises when setup the "Language & Region" (Settings => General => Language & Region) as follows:
"iPhone Language" to "English (Canada)".
"Region" to "Jordan".
However, (as mentioned answer for: How to get detailed language of device in swift calling:
print(Locale.current.identifier)
Logs:
en_JO
which is an invalid local identifier (Logically speaking, Jordan is a Middle-East country which its native language is Arabic not English).
I also checked the availableIdentifiers:
print(Locale.availableIdentifiers)
and -obviously -it does not contains "en_JO".
Also, I tried:
if let regionCode = Locale.current.regionCode, let languageCode = Locale.current.languageCode {
print("\(languageCode)_\(regionCode)")
}
and the output was the same.
It seems that it has nothing to do with identifier validity, but how can I make sure to get a valid identifier? As an example, in my case the expected result should be:
en_CA
So what am I missing here?
There is nothing invalid about the identifier en_JO. The identifier is completely valid per the Unicode standard as an identifier for English in Jordan region.
However, that does not mean data for that region has to be available. The system is not required to have data for every crazy combination of language and region.
See Language Matching in the Unicode standard. If there is no data for the requested locale, a fallback locale is then used, in this case probably the locale en.
Every locale identifier includes a language code(e.g. en) and a region code(e.g. JO). This much is evident from Apple's documentation:
A locale ID identifies a specific region and its cultural
conventions—such as the formatting of dates, times, and numbers. To
specify a locale, use an underscore character to combine a language ID
with a region designator
This means your statement that en_JO is an invalid identifier is incorrect. It is formed because you have selected english as a language and region to Jordan.
Now, if you want to get only langauge part, you can get it by preferredLangauges,
let langId = Locale.preferredLanguages.first
or by collatorIdentifier on current Locale
let langId = Locale.current.collatorIdentifier // returns optional string
How do I change a currency in a Latex template? Something that's text based, like South African Rand (symbol > 'R'). Latex doesn't recognize ZAR etc.
FYI: I'm currently using an invoice template.
Within invoices, or any template containing a currency you'll want to change, simply write the next:
\documentclass[letterpaper]{dapper-invoice}
\renewcommand{\$}{\text{R}}
In the above instance, I'm changing $ to ZAR (South African Rand). It's a simple way of changing the currency to a text-like currency (eg. 'R').
Documentation for the availableLanguages method of UITextChecker states that:
The languages represented by the strings in the returned array are in
user-preference order.
Exactly where does the user set his preferred language? Settings > General > Language & Region does not change the returned list of languages... so what does?
For example, printing available languages:
println(UITextChecker.availableLanguages())
shows me:
[en_CA, da_DK, en_IN, en_US, nl_NL, en_AU, fr_FR, pt_PT, en_GB, es_ES, sv_SE, ru_RU, de_DE, tr_TR, it_IT, pt_BR]
Apparently the preferred language on my iPhone is set to "en_CA" which is English->Canada. I would expect "en_US" to be first in the array since I live in the United States. How can I make changes so that en_US is first?