Just my 2 cents: - web2py application and desktop application will probably read the data a lot, updates not so often - additional strings in web2py application gets "automagically" added to the language files
The only doubt remains the one: if you need to add something to language files within your desktop app, did you figure how to do that? If this is the situation, can't you implement a simple "copy" of all the languages files back and forth to be activated when it's needed ? (seemingly when a string gets added from your desktop app you'll do desktop/language-->web2pyapp/language, when a string gets translated by the admin app in web2py you can do web2pyapp/language-->desktop/ language) PS: if you're willing to hack a little bit, gluon/languages.py and get_possible_languages() in the class translator are where it appears to be defined the location of the language files. On 3 Dic, 23:06, Alan Etkin <[email protected]> wrote: > I found this: > os.symlink(source, link_name) > > Just supported in Unix type systems, so i cannot use it > > On Dec 3, 6:21 pm, Alan Etkin <[email protected]> wrote: > > > > > > > > > I know it is a unconvetional way of managing language files, but i am > > working in a project wich has a desktop Python application and a > > web2py application and both of them will share translations. > > > I do not like symbolic links for this case because i don't know if it > > there is a way of setting them for all common operating systems at > > installation (anyway, i suppose there must be a pythonic way using the > > standard library). I think it would be simpler configuring the web2py > > app T object. > > > I am trying to make that the web2py app load the language files from a > > folder in the desktop application, but i did not find a way of setting > > the T object folder so it can read the files and at the same time, the > > translations from the web application (from the admin interface) be > > written in those files. > > > I've seen the folder T attribute but i think that setting this > > attribute isn't enough to solve the problem. > > > Has anyone had a similar problem? > > > Thanks
