I think this is a very good approach and if it is done correctly it will give TERP a boost in the way it is seen/experienced by new users.
Some more thoughts.. Location of Changes: Fabien, are you planning to change this in code and in the Basic XML files or are you using an localisation/l10n file for lets say en_UK language? The former would mean that some translations get lost, with the later approach you have for english the same advantage as for the other language packs. Simple real time editing and changing - together with the users maybe. This could help to get it modified to a customers usage/like for some installations. The original wordings inside the code are called pidgin en for example and are somehow like msg-IDs. Help translations: Make help text translateable and editable in the views. This way also a translation of the mouse -over help is available to the user. Further advantage is that later one can dynamically create a manual from the detailed field descriptions maintained in the help text, it would also work as a kind of data repository. Central translation database: Sorry, this is maybe overkill - but I dream of it. Instead of keeping the different localised versions in seperate CSV files - which is messy and error prone why not hold all in one huge table. The structure would be the same as inside the TERP database, maybe with some extensions to tack change history. >From here automatically extracts can be done (into CSV or JSON) and some >interactive access - either via TERP or via a seperate web frontend (a small >Django App?) - is given. In the interactive access there is a kind of list view - showing the original (I did call it pidgin) value together with the help text explaining the meaning in its context. I imagine it could look like pidgin value (Source) - original help (eg. en_FR) lang A value - lang A Help (eg. en_UK) lang B value - lang B help (fr_FR) ..... ... lang M value - lang M Help (eg. en_US) which is similar to the view in TERP - just blown up As the english localisation is also only a additional record, it is shown, and here the value and the help content can be modified once better wording pops up / evolves. A discussion board (like a very simple comment blog) would ease collaboration on difficile words and help to track the changes. Of course there will be access issues and spam and stupid changes - but it might be a way to get a very powerful repository - from where simple manuals could be generated semiautomatically - just give for each field the name and its detailed description. You could even think about autotranslation of standard expressions - once agreement is that for a given pidgin word 'X' the translation int lang A is 'Y' and into lang B is 'Z' - then next time the same pidgin is used all ocuurences for A and B are are filled automatically. Some queries enabling special views like the one in http://tiny.be/download/menus.txt could be later added - this way giving always convenient and up-todate reports of the structures. Hope this makes sense and doesn't sound to confusing, rgds Günter _______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman/listinfo/tinyerp-users
