Forum Discussion

YannickYannick's avatar
YannickYannick
Qrew Member
11 years ago

Is Quickbase usable for non-US businesses ?

Dear QB community,
I am evaluating Quickbase for a french speaking organization.

I understand that Quickbase only have english menus, does only supports dollards as currency sign and US date format.

I understand that there is not current commitment from Intuit to provide a i18n compliant version of Quickbase in the near future.

My user base will be fine using english for the navigation menus but all the texts in the data and data-field labels will be in french and therefore often uses non english characters such as ?,?,?, ?, etc.

From my tests and some other community posts, it seems that Quickbase is quite unreliable to manage non US characters. See for instance this post (https://quickbase-community.intuit.com/questions/167110-hello-all-i-m-having-issues-with-names-that-...), 5 months old and without any solution it seems.

I am close to concluded that Quickbase is unusable for non-US businesses.

Is there any body around here who uses Quickbase seriously in an non-US business with significant non-american texts data in their database ?

Any live experience on this ?

Any user in a french speaking country around ?

Many thanks !

Yannick

6 Replies

  • I work for a company that has many 'sister companies' of which the users are ether English (UK) or English (US) but not a mixture in the same company.

    The applications which I use solely for my UK Users, I have found that while you can change the Currency symbol (to a � or anything really) it does not export as a � but as a dollar - this is a bug which I have reported. I tend to use Numeric Fields and in the label put the currency code.

    In regards to dates, it does use the American format but again for my UK users, I have it set so that the date displays as "Jul-22-2013" which gets round the issue easily.

    I don't really have any experience with the accents in letters so can't comment there.

    So in short, yeah it has some pitful (No idea why you can't TRUELY change the date format for example) but I work around them as the design and customisable side of Quickbase over shadows the other not so good bits around international compatibility.
  • Hi, yes we use QB in Montr�al,Qu�bec, but mosltly our collegue in Ontario also reads the info , that',s why it's in <Anglais> but i find that it's only bad for filetring reason. I heard that they were working on a international version, no confirmation ?

    Because QB is so good , dont mind using the <English > for dates and pas d'accent...

    Bonne journ�e
    Alain
    Montr�al,Qu�bec
  • Hello! I wanted to let you know the option to change the currency is now supported by QuickBase. Common currency symbols now supported included: US Dollar, Australian Dollar, Canadian Dollar, Singapore Dollar, British Pound, Japanese Yen, Euro, Indian Rupe, Chinese Yuan and Hong Kong/Taiwan Yuan.

    You can set the date format one of three ways. First you can go into the Manage Billing Account and then into edit account properties and make the change for any application on the account. Second can set it field by field by editing the properties of that field. Last you can also set it for the whole application by clicking on App Properties from the App Settings. Saving the App Properties will make that the default for all new fields. It will not change fields that were made prior to the save.

    You can also set the date format for the application there as well. This has to be done in the App Properties as there is not the option to make this change in the field properties. Saving that will change the format for all date fields in the application regardless of when they were created.

    You can read more here:
    http://quickbase.intuit.com/downloads/QuickBaseReleaseNotes_Oct6.pdf
  • Hi,
    I have developed a bilingual app for use in New Caledonia. I have definitely had some issues. The worst being that the csv sync will not work with French characters. Everything else has a work around. For currency, i just leave the currency values as numbers, and state the unit in the field name.  E.g [Cost (XPF)].

    Dynamic filters don't work on french characters either. Half of my data and field names are in french and for the most part i find it useable but slightly annoying.

    I also found customising field access for roles want possible with IE because it can't handle the French character field names. However, Chrome worked just fine.

    Android displays french characters in quickbase as a diamond "?". Refreshing the page (pull down and release) showed the French characters.

    Hope that helps.
  • Hi,

    I am from Brazil and have been using QB for 8 months. In portuguese language we also have some characters that Quickbase doesnt handle, like �, �, � etc.

    So, we are experiencing the same problems that you and Matt had pointed above, like filtering inacurracy and characters change in Android display.

    What really bothers me is the fact that QB simply doesnt seem to care about that. The support for international language is not in their roadmap (if I am wrong, please someone corrects me) and they dont even have replied for your message posted 4 years ago.

    So, at this time we are dealing with this limitation and looking for another incoming solution in low-code development: google has launched the App Creator, for example.

    QB is helping me a lot, really. This lack of interest in making it trully international is the only issue that makes me keep looking for another solution.

    Regards,

    Daniel
  • I mean the comments I am about to make in the most helpful way - to improve the product and the value  users derive from using it. However, I wish QuickBase would stop implemented hard-coded features such as (1) only supporting particular date formats or (2) only supporting a limited (and outdated) set of HTML tags in text fields, (3) making it difficult to use JavaScript on pages, (4) lack of Unicode and locale support, (5) lack of branding, theming & customization etc.

    I think the project managers / business analysts at QuickBase have the wrong mindset and keep trying to push isolated, single purpose hardcoded product features decided upon in meetings using the pareto principle (80/20 rule). Users want greater ability to to configure the product without hitting arbitrary limitations and this requires the ability to add small but essential fragments of html, css and JavaScript.  They want more integration hooks. This "no code" meme is a myth - during the course of any successful project some unique requirement always rears it head and it requires customization and some level of "coding" to solve. Additionally, QuickBase can't add hardcoded features to the product fast enough to keep up with diversity of user's requirements or to avail themselves to the endless cornucopia of features added to the browsers.  

    Remind me to schedule a vision quest with Rick Willett to convey these ideas.