I would like to comment that the idea of having translations of file and folder names is not a valid approach to handling localization. There are several problems with that approach. You will not find any of the major operating systems that do this. Localizations are for the UI elements of applications (including the OS), but not for data. Files and Folders are the 'data' for the OS, in one sense.
1) If you show a translated name for a file or folder, the user will have no idea what the "real" name is for the object. 2) When writing a program that accesses files or folders, I don't want to have to have the program "know" about the 'aliases' for the object. 3) This will impact the run time of applications as they search through the aliases when looking for the proper object. 4) Very often the translation of a word is context sensitive. A single file or folder does not have a context, so the translation is ambiguous. 5) A single word in one language can often require a translation into a phrase of multiple words in another language. 6) This will impact name collisions when doing the translations. For example, let's say a French speaker creates a directory named "contenu". Then an English speaker creates a directory named "contents" in the same parent directory. Since the translations of those words are each other, it would be impossible to have a correct translation for those objects. 7) If a Russian speaker creates a folder using Cyrillic characters, the name of the folder is the Russian name, NOT a Chinese translation of the Russian.
My day job is in the globalization division of one of the world's major software vendors (over US$2Billion in revenue last year). While I understand why you want to do this, it is REALLY A BAD IDEA.
Michael Bridgers On 2/18/2011 10:51 AM, Ingo Weinhold wrote:
On 2011-02-17 at 17:50:55 [+0100], Jonas Sundström<jonas@xxxxxxxxxxx> wrote:Axel Dörfler Axel Dörfler<axeld@xxxxxxxxxxxxxxxx> wrote: ...missed the possibility of live updates (ie. when the user changes the language).Couldn't that be accomplished by sending a language change message via BRoster::Broadcast()? How to respond to that would be up to the applications, including Tracker and Deskbar. (Or a future BRoster::Broadcast(bool limitToSingleUser))I would just have the key in "sys:trans" (or whatever it'll end up being called): Tracker can then look it up in either some shared place (for system resources), or even in the app catalogs for applications. Since you probably rarely have hundreds of translatable items in a folder, the speed penalty should be bearable.Yes, I suppose that in practice all catalogs will have the app name, but what if there are multiple differing translations of the name string in different contexts?Then optionally also put a context in the attribute. The attribute format could e.g. be: <catalog signature> [ ':'<context> ] ':' [<key> ] If the context is not given, a default context could be used (e.g. something like "FS entries"). If the key is not given, the file name would be used as a key -- though that might be considered too fragile.If the key in the attribute is set to point to a specific catalog entry, who does that and when?The creator of the entry would need to do that. This would be the developer/packager who puts the file in a distributed package. When created by an application, the application would do that. I guess the latter case is relatively rare, since most applications will create document files whose names are specified by the user anyway. To simplify setting the attribute an application or Tracker add-on could be provided. On 2011-02-17 at 18:11:18 [+0100], Jonas Sundström<jonas@xxxxxxxxxxx> wrote:Ingo Weinhold Ingo Weinhold<ingo_weinhold@xxxxxx> wrote:[...]As for implementation: Apps would store a list of translated names in their own resources (which are embedded in the executable)Why not in a catalog?I find this data to be very similar to the standard data of the app resource, some of which also gets published as attributes. Having .rdef files in our repo makes the app name translations sort of more official, canonical. For better or worse. I don't know. I guess catalogs should work just as well though.The advantages of catalogs are that 1. there's already an infrastructure for translators and 2. there's already the catalog framework for accessing localized strings (so why add another one?). [...]Folder (and file) translation data could be kept in some shared location i.e. in /boot/common, managed and updated by the system, and be applied to all the respective folders when the user changes the language setting. (It could easily update apps the same way.)Again, I would use catalogs.I thought it would be simpler with attributes, but maybe it doesn't make much of a difference.It may seem easier to get a translation (by just reading the attribute) but language fallbacks (e.g. 'en_GB' -> 'en' or using an altogether different language, when the first preferred one isn't available) already add a bit of complexity. Adding translations for a language to individual files is definitely more complicated (particularly when, as for packagefs provided ones, they are read-only), than simply dropping a new catalog somewhere. Furthermore, though probably not particularly important ATM, different translations for hardlinks are only possible when the key and translations are not directly attached to the node. CU, Ingo
