|Many people doesn't speak English, so, It seems to me that it is necessary having a multi-language option. In my case I would like to count with Spanish. |
|terry cheng||jecki elbaz||Isaac Dai|
|Jeff Aibel||Leandros Papadopoulos||John D’Amelio|
|Daniel Luz||Alfred||Bin Xia Zhang|
|basenine||Jorge Solá||Andrew Hobbs-Ray|
|Alexandre Cunha||Desmond Beatty (Conc)||Robert Gustavsson|
|Dean Eberly||Ron Thomassen||Ton Jense|
|Jan Schoon||Desmond Beatty||Rick Cogley|
|Francois Garon||Daniel Vazquez Ger||Philipp Matuschka|
|Liquid Rapid||Rick Cogley||DonJ-Adi Marketing Expert|
|Christof Sulzer||Ingmar Groppe||Alfredo Bravo|
Rick Cogley 7/2/2010 5:01:46 PM
It would be a plus, to be able to have UI elements in native language. I would imagine that a form could be created somewhere by ForeSoft, for people to contribute to translations, centrally. I know we would do the Japanese. Even having the basic UI elements in native language, would be helpful.
| id | element | English | Japanese | Spanish | German | French | ...
| 1 | var_save_btn | Save | 保存 | ...
One challenge is grammatical order and cultural expectations. For certain elements on the screen, in English we would say [This: X] but in Japanese it might be [X number of This's].
That being said, the Admin UI is OK (for us) in English. I imagine computer people are used to having Admin UIs in English, here and there.
Where I would really like the multilingual ability, is in the User UI side. I can replace display strings with Japanese if I need to, but, this is hard-coded. I can force Japanese for Table Names, View Names, Dashboard elements and so on, but what I would like is, to have a way to assign a name depending upon language. Perhaps the first-entered language is English.
It would be good if there were an option to attach a string for Language X or Language Y, to each label, where I need the ability to automatically switch. Then, when user A logs in with "English" as their setting, the English strings show up, and when user B logs in with "Japanese" as their setting, the Japanese strings show up.
Philipp Matuschka 10/21/2010 3:08:35 AM
I see that I can now select which language a user speaks. Is it planned to have this support fuyll multi language? My users are German and/or English speaking. It would be very useful to be able to present field names etc in two languages.
Liquid Rapid 11/9/2010 11:53:18 AM
This would be useful for me as well. As it is, I have two languages in every column name / form section header / table name. It makes for long names. With more than two languages, it would become impossible to do it this way.
Name Nombre (column name)
Times Tiempo (table name)
Details Detalles (form section header)
What I'd really like to do is specify in the admin interface, for every object, separate object names for specific languages:
Column ID 123
Table ID 890
Form Section Header, Element ID 543
And so on. Then I could simple tell people to select their preferred language on their Personal Information page, and the system would show them object names in just that language. This would make for a lot of happy users who currently don't like the English in the apps I work on (but since I don't speak their native language, I need the English in there for development).
Kirill Bondar 2/11/2011 3:34:27 AM
378 - Multi language
Rick Cogley 3/1/2011 6:20:29 PM
This is becoming more and more important, as our mostly-Japanese user-base is sometimes asking us: "why can't Cancel be in Japanese?" and the like, pointing out the system buttons that we cannot change.
We are also finding these challenges:
* if we make field names bilingual, so they filter thru to forms or views, formatting is a bit off due to the width
* if we make field names Japanese, English-speaking developers are hampered because they cannot easily read the names
Philipp Matuschka 10/22/2011 7:24:06 AM
Can I make a suggestion as a short term workaround with which I could address 95% of my issues, which are now ever mounting.
In form layout, edit columns, it is currently possible to enter an alternative label.
a) make it possible to put a variable name in here. I could then pick up the field name from my own language table, based on the language selected by the user.
b) provide the same functionality for Views.
Daniel Vazquez Ger 10/22/2011 11:30:07 AM
Great Idea !!
Rick Cogley 10/23/2011 6:48:49 PM
Yeah, that would be helpful. One thing we consistently get complaints about is why the base Edit and Cancel buttons are in English.
Philipp Matuschka 1/10/2012 11:52:35 AM
We are about to take our application out of internal only use and make it available to many of our german trading partners. Most of these do no speak enough English to be able to use it in English. We are being blocked by the lack of any form of multi language. Could I ask you to at least consider my suggestion of October 22nd.
Jan Schoon 5/18/2012 11:41:59 AM
Is it possible to make a localisation for Dutch, so buttons and menus are easy to use for my users?
(Or perhaps it's possible and I haven't found the way yet...)
I would be happy to assist in translating.
Please let me know.
Jan Pieter Schoon
Slava Shinderov 5/18/2012 11:57:56 AM
514 - Dutch language
Daniel Vazquez Ger 5/28/2012 10:39:52 AM
Ron Thomassen 3/20/2013 3:00:10 AM
We also prefer buttons in the Dutch language.
Dean Eberly 4/1/2013 5:43:14 PM
Very helpful idea! This would make Teamdesk much more valuable globally. How about the entire database appearing according to the user's language locale?
Robert Gustavsson 4/11/2013 8:49:29 AM
I would like to see the keywords ("Add/Edit/New...") substituted on the table level, to a default word for the chosen country, but modifiable (for grammatical reasons).
Supporting formulas as keywords would be "overkill" for our purposes.
Desmond Beatty (Conc) 4/3/2014 10:22:45 AM
As part of "Multi-Language, please consider improving the determination of usage of "Language and location" settings in TeamDesk.
"Language and location" can be set for the Database and, separately, for each user.
Support advise that TeamDesk uses user-specific settings wherever possible and falls back to application settings as the default. Specifically, for email workflow actions and email actions, where the TO: recipient listed is a user, the locale/timezone of that user affects the formatting. When the TO: recipient is an arbitrary email address, the locale/timezone of the application is used for formatting. (CC: and BCC: recipients are determined by the TO: recipient)
Our specific situation is that we have users in more than one "Language and Location" e.g. English(Ireland) and German(Germany). German is significant for us in that numbers are formatted nnn.nnn,nn (and not nnn,nnn.nn)
For general/default purposes, we want our database "Language and location" to be English(Ireland). For a specific email workflow action, we want to send an email with an attached Document ALWAYS formatted German(Germany) but to a non-TeamDesk user only. (one workaround is to make them all (v. passive) users.)
Our idea is that, for email notifications and workflow actions, the choice of source of "Language and Location" (and perhaps the timezone, too) be made available in SetUp eg a checkbox or equivalent on the From, To, or Application. Alternatively, a dropdown with choices such as T0: FROM: CC: BCC: Application: and the full list of "Language and Location" from which one can one that is not the Application setting.
Desmond Beatty (Conc) 4/3/2014 10:26:14 AM
Another option might be to allow selection of "Language and Location" for specific documents. This has merit in that often times, documents are country or language specific and Multi-Language system need to be able to select which of a range of Documents to send based of specifc "Language and Location" parameters.
Jorge Solá 7/11/2016 9:11:47 AM
As it is right now, it’s impossible to build an application in a language other than English that will not have some elements left in English in the User UI: the standard buttons (NEW, PRINT, EXPORT, etc.), some words (Action, Views, Search for keywords, etc.) It’s not much, but it’s enough to make the user experience less pleasant than it could otherwise be, especially in applications geared to the general public. From the comments in the Forum section I’ve seen that you have quite an international user base, so I would think that maybe it’s time to change the multilanguage approach.
1) The first thing would be to have all the buttons & messages in the UI display in whatever language has been chosen in the Database preferences.
2) Next could be to give individual users the possibility to choose the language of their choice for those databases that are built to serve more than one language area (for instance, German & English, Dutch & English, Japanese & English, etc.)
3) You could also consider making the Setup UI multilingual as well. At this point, anybody attempting to build something in TeamDesk needs to have a pretty good knowledge of English if he wants to get anywhere. Making the Setup UI truly multilingual could potentially multiply the number of individual users in non-English countries, who right now are forced to go to a local company & ask them to develop something for them because they don’t have the tools in their own language.
4) At some point it would also be necessary to translate the documentation into the main languages that you might want to target.
Since we own a translating agency in Colombia, we are well aware of the frustration & powerlessness that people experience when they don’t have the means to overcome language barriers. I can guarantee you that it’s much easier to set up a multilingual interface than to get everybody to learn English. This is an issue that TeamDesk will have to tackle sooner or later.
Rick Cogley 7/11/2016 4:33:24 PM
I'd like to see the UI buttons be translatable, and really agree with that point. Various members of this community can help with it, and, I think it should be able to be done via a setup UI like the one used for dbflex.
I think translating the setup UI or user docs is too large an undertaking, though, and would rather see the Foresoft team focus on important features. If it's written in a language, people will expect support in a language, and that does not feel realistic to me.
Philipp Matuschka 7/13/2016 2:11:39 AM
Still interested in seeing a solution here. Suggestions already made above years ago.
Minimally to be able to see buttons like EDIT, VIEW, etc in multiple languages and to be able to give Tables, Columns, Buttons, View, View categories Dashboards, Sub tab names, form sections, form text fields names and content in multiple languages. IE anything the end users sees.
While I understand where he is coming from, I don't share Jorge's need to make the setup area or documentation available in multiple languages.
Daniel Luz 12/1/2017 4:26:47 AM
Hi TD Staff,
You don´t need to translate the hole platform, only some "basic buttons" like: Buttons: NEW, VIEW, EDIT, DEL, ACTION, VIEWS etc.
Daniel Vazquez Ger 2/19/2018 11:51:31 AM
This idea is very very importante....
Daniel Luz 2/20/2018 2:17:04 PM
Hi again TD Staff,
I would like to inform you that I have presented Team Desk to my MBA classmates and almost all of then got very intersted in TD.
But, some of then asked me about the languages supported by the platform. So, I would really recomend you to invest in this feature.
Jeff Aibel 3/18/2019 4:06:54 PM
We have a need for forms to be completed in 13 different languages. It would be very helpful to have alternative labels for forms in different character sets and allow the user to select which set of labels that the forms would present.
Jorge Solá 3/18/2019 7:59:03 PM
Jeff, I would think that your only option right now is to create 13 different sections in the form, one for each language, & to create in each of those sections the different columns that you need. Then have a text column at the top with a dropdown menu where the user can select his language. According to the language selected by the user, through form behavior you can show the corresponding section & hide the rest. Then you can have a record change trigger so that, when the record is saved, the info the user has input in his language section is copied to the "main" language section.
Jeff Aibel 3/20/2019 1:55:10 PM
Thanks for the suggestion – I was trying to avoid that because of the extra work but it might be the only reasonable option. I’ve never worked with different character sets, do you know how TeamDesk can pull in different character sets for the different sections? Can you point me to a resource?
Jorge Solá 3/20/2019 10:22:58 PM
Jeff, I've only had experience with English, Spanish & French in TeamDesk, & the special characters in Spanish & French are handled well. But I can't tell you about other character sets.
Isaac Dai 3/28/2019 2:39:21 PM
I can contribute to the Chinese. I am building a database with Chinese database and it runs great. The only missings are the system language.
Robert Gustavsson 7/23/2019 2:48:16 AM
Also, strings need to be indexed in a better way. As of now, if I search for "BergshÖjden" nothing is returned, but if I search for "BergshOjden" (without the dots) then "BergshÖjden" is returned (!).
Generally words should be indexed and searched for after being converted to a simplified phonetic representation to increase user friendliness in searches.
|Back to Search Results|