Language can be understood perfectly without diacritical. Short message are widely spread and don�t use them.
Some banks (Ex a Caixa) do not accept diacritical�s in the transaction!!!!
Most important setbacks:
a. - Not being able to filter words with diacritical�s.
What I do in some cases I have to Data fields. One with diacritical�s to view en another one without just to filter.
I use some regex such as
var valorFormat = row["valorUnitario"].replace("R$", "\ ");
var valorFormat2 = valorFormat.replace(/\s+/g, '');
But have not managed to be consistent in the transformation.
Would be nice to be able to substitute while writing, in SOME ESPECIAL DATA FIELDS THAT YOU PREVIUSLY KNOW YOU ARE GOING TO FILTER
b. - After importing something from excel etc. Database gets corrupted with strange signs.
Most of this things can be solved by Orienting customers how to set browsers and excel, but there is no a One Place to look at, so we learn by experimentation.
ONE IMPORTANT THING: CSV formatting here in brazil is a little bit crazy and does not seem to follow a strict standard. Sometimes comma sometimes semi coma.
c. - Most users get paralyzed when they see a pop up in �ENGLISH�.
There are few pops up so when they learn what it is it is ok. Even though for a deployment I think that service worker translation can be a solution.
There isa standard Brazilian keyboard used and if so are there special keys or key combinations used to enter diacritical characters?
4.- In some cases you have to create an extra Formula Field to get things done in table to table import etc but is quite simple.
Hey Evan Marrtinez and Sam Jones why is QuickBase using Windows-1252 encoding and what are the plans for using UTF-8?
Convert QuickBase from English to Portuguese using a Service Worker and develop the Brazilian market.
var str = "�, �, �, �, �, �, �, �, �, �, �, �";str.normalize('NFD').replace(/[\u0300-\u036f]/g, "") // "c, a, e, i, o, u, a, e, o, a, o, a"