Jessy (it's that your name?),
I see you point, but again:
- we cannot rely on any external services for translation: this will tied dnn to a specific provider and this is completely oposite of what we want. Even if we got it configurable and independent from the translation provider, we cannot base it on a third party resource.
- when developing modules you usually use vs.net which cames with a wonderfull editor for xml files. So I still don't see any advantage on your option. And saying that it will handle 50% of the work...I think you're quite optimist... We usually then to use "compact" control names (say "lblUserName") but the actual next in most cases is not the same as the control name (say "Enter the user name").

You can think this as separate helper for translators or module developers but I don't really see this being added onto the core. If it works for you great! I (as a developer) for myself wouldn't use that approach (automatically adding resx keys) since I don't like that approach. I prefer to control the whole process when I'm creating the module on vs.net, and not having to go to the run the app in order to have the keys added.

---

Vicenç Masanas
Banyoles, Girona - Spain

   

We have a database with around 80 tables, each table with around 5 different ascx controls.  We want to create a database based data dictionary for these terms so that we can automatically create resources files in different languages based on:

i) The English resource files we have created.

ii) The data dictionary

A great solution for DNN would be an automated translation that works by using an internal data dictionary (as above). 

A second phase of this project could be the facility to use a "Translator Provider" to populate (translate) terms in the dictionary that were currently without translations.

We may have some funds to implement this and it would be great to do this in a way that feeds back into the core. 

Would either of you be able to estimate the work involved here?

Hi,

as far as I understand, you're looking for a resource file maker in the form of a module with an engine that binds to a translation dictionary in the database.

Vicenç can probably confirm that, but I don't think that's what the next steps of dnn loclization will aim for, since content localization and validation workflow will rather base on duplicating the structured data through foreign keys than tapping into a non structured data source.

On the other hand, such an engine is pretty much what our module does, except than it taps into a translation web service rather than a dictionary table.

Can you precise the kind of interface you'd like to see?

Maybe something like:

• An alphabetical view grid / tree view for browsing the dictionary
• An edit form for adding / editing translation entries
• A form to configure / launch the engine that creates / updates the resource file

 just a few days of programming it seems to me.

---

Jesse CTO - Aricie