Hi,

would it be possible to have the build in localization of the framework into something like the 'Common Repository'?

This would be much more comfortable if it should be necessary to correct some of the view remaining translation errors of the framework in german (in my case), or if someone likes to use own translations for some reason.

I don't like it to be asked in german if I really want to close 'the application' instead of the ' the window' like it is right now in some cases. And I hate it always to have to change xml-files and to compile the source code of the framework over an over again with any new version, even with betas. But I would love it if there would be an easy way to correct such translation errors by myself with the given tool called 'Message Editor' of StrataFrame! :-)

Could something like that be taken into account for the next generation of the framework?

Thank you very much and friendly greetings,

Ralph

If I understand you correctly, you are just wanting the pre-localized messages of the framework to be in the common repository.  Really this would be quite difficult at present as each assembly requires it's own localization project.  So at present, this would not be possible just by the nature of how embedded localization works.  For example, the UI assembly has its own localization project as does the Base, Security, etc.  It is important that they be separated so that each project can import these exclusively.  By them being in the Common repository, this would not actually work when brought into each assembly.

Also, if I understood this correctly as well, it sounded as though you are changing the XML files within the framework source.  This really isn't recommended as the very next version of the framework will break this when loaded and require you to manually update those assemblies as well.  Now you are welcome to take the translation packages, update them, and then send them back to me...which I know is more work.  But this would at least ensure that things don't break down the road.

Finally, localization is already on the slate for a pretty big overhaul.  There are dozens of new features that we intend to implement to make this very type of thing easier.  And I do see the validity of your suggestion, but there is not an easy way for this to happen at present.  But for now, you may consider using SQL Server (while in beta) so that you can manually update these values in the database versus in the XML file and prevent an app rebuild.

Hi Trent! :-)

Great! :-)

I can see that and that's why I asked it for '...the next generation of the framework'

How would I do that for the pre localized messages? I thought the xml files have to be embedded into the dll's after compiling?

It is not because of the work, Trent. It's because the translation has to be done without the context of the messages. I think Bastian Töpfer did a great job, much better than I could have done. But it is really difficult to translate something you don't know where it would be used. There are many ambiguous words which could be easy mistranslated.

And there are only a few messages left which actually could (maybe should) be changed and a few less, which I would translate another way but with the same meaning. So there should be no need to translate again what's already translated. Nevertheless I'm going crazy every time I face one of the left translations which I would prefer to have translated another way. I hope you understand what I mean? Before StrataFrame I used another .NET framework which let the end user translate any label of any form and any message used, and that at runtime while in context. That's what I really miss. But I would miss also really a lot if I could not use StrataFrame. At least I prefer StrataFrame for some reasons. I love it! :-)

If you could tell me how to use SQL tables instead of xml files for the pre localized messages? That would be great! :-)

Thank you very much, Trent.

Friendly greetings,

Ralph

I am familiar with this framework and this approach requires the end-user to localize their own application...and approach that we thought was wrong.  As I have already mentioned, you could technically do this already using SQL Server or an external XML file.  In regards to the internal SF keys...this is more than likely not going to be something that is going to happen anytime soon as addressed in my previous post.

In regards to the SF keys coming from SQL Server, the bottom line is that the keys just need to be in whatever localization source you are using...including the SF ones.  So if you were to extract the keys into your own SQL Server messaging tables, then set your localization environment to pull from SQL Server instead, the SF assemblies would look in that SQL Server message store...thus, allowing you to change them.  You would just have to open up the XML localization files, copy out the keys, and add them to your localization solution....this would require a lot of work and I recommend against this as there could be some other issues as well, but that would at least be an option if you MUST have it this way right now.

Hello Trent,

An approach like that is surely not completely wrong in my eyes, because nobody would keep you from including some localized messages into the framework or deliver a few localized messages (tables or xml-files) with the framework. This is what you do right now, but unfortunately without an easy way for the developer to modify a message, label or whatsoever. Not to speak of the end-user... Or a translation while in context...

After thinking about your suggestion I found it would possibly be a very hard way. ;-)

And I don't want to have it right now, but it would be nice to have something useful into one of the next generations of SF, maybe 2.0?

I let the app at startup look for the appropriate xml-files and if no localization is found this way, my app tries to using SQL tables instead. Until now, while at development and learning the possibilities of the framework. ;-)

So far, so good. :-)

You are kidding me! :-)

This would be more work than it is worth of... But a nice joke anyway! :-)

You say it clearly: A lot of work. So much work that I'm due to retirement before at the end of the work for that single task, I guess. ;-)

This is why I was asking for something for the next generation of SF.

I'm sure you will surprise us with something really great! :-)

Thanks and friendly greetings,

Ralph