You need to sign in to do that
Don't have an account?
Thomas Stroh
Basic Database Design & Localization
We have translation toolbox enabled and it does the job with basic picklist, field titles, etc. We will not be using picklists anywhere in our solution for a couple of reasons; most importantly, that we must use lookup tables in order to add associated columns.
As a simple example, we need a lookup list that contains "Colors", containing “Red”, "White" and “Blue”. We may also decide later that we need abbreviated titles, hence “R”, "W" and “B”. Later we add other associated values, and so on. And secondly, "Colors" needs to have references to more than just one Object, so why manage the same pick-list values in each Object referenced?
For the sake of scalability, Colors must be in a table (or Object) rather than a picklist. The problem is, we don’t know of a way to provide translations of lookup tables. Yes, we could add columns like “units-de”, “units-es”, etc. In order to use the proper column in the UI for the current locale, we would have to write s-controls for every affected object. There has to be an easier way.
So what are you doing with these associated columns exactly?
You do have a point about the joins on picklists -- it would be nice to be able to do a report joining 2 objects based on equivalent picklist values.