updating the database when applying changesets

Hi,

I've been wandering about something today.

Whenever a database is changed the file with changescript is appended with new commands that change the database. This is fine when updating between full version eg. 2.4 -> 2.5. However developer style updating within version is problematic.

One can of course extract the commands added since the time script was last executed - a bit of work but not a problem. However using database version numbers could solve this. Each time a new set of changes is applied to database a version number is bumped up. Change script than contains version check which executes only the parts of change script that we're not yet executed.

IF (VersionInTheDatabase < 1152) THEN

BEGIN
//command go here

SET VersionInTheDatabase = 1152

END

This is just a thought of course - maybe this is too much hassle for a simple thing.

Language strings

Slightly more problematic are the language strings. Currently the script overwrites the strings in all languages. Needless to say I found myself translating some of them between version releases as I often run intermediate ("cutting edge") versions. I was wandering if it would make sense to change the default behaviour. At the moment the only language installed out of the box is english so obviously the strings for english could be overwritten. For other languages I would suggest creating them only if they don't already exist. Further they could be created with some sort of flag (either extra column - let's call it "untranslated") or a marker in the translation itself (I append " [en]" to untranslated strings).

insert into LocaleStringResource ( LanguageId, ResourceName , ResourceValue)
select 2, ResourceName, ResourceValue + ' [en]'
from LocaleStringResource
       where
      LanguageId = 1
       and ResourceName not in (select ResourceName from LocaleStringResource where LanguageId = 2 )

In above example 2 is the "new" language - obivously this would need to be loped over all non-english languages.

The english name + [en] looks relatively OK on the website and prompts the store owner for action.

If untranslated strings can easily be found than I usually run a simiple SQL to get me the untranslated strings and than to translate them.

SELECT     Id, LanguageId, ResourceName, ResourceValue
FROM         LocaleStringResource
WHERE     (ResourceValue LIKE '%\[en]%' ESCAPE '\') AND (ResourceName NOT LIKE '%Admin.%')
ORDER BY Id DESC

Of course a simple screen in the admin section that would do the same thing would be more user friendly to the general population of webstore owners who find their language beting supported by language pack from previous version of nopcommerce.

Just a thought..

Filip

Hello Dear,

Please create a new language for Poland.
Download an XML format which is the default English language pack.
Make the desired language translation of an XML editor.

<?xml version="1.0" encoding="UTF-8"?>
-<Language Name="English">-<LocaleResource Name="AboutUs"><Value>About us</Value></LocaleResource>

<?xml version="1.0" encoding="UTF-8"?>
-<Language Name="Poland">-<LocaleResource Name="AboutUs"><Value>O nas</Value></LocaleResource>

İmport of Poland Resource.

Regards,

fkierzek wrote:
There's no any issue with it. You can execute an upgrade script as many times as you want. There's no need to execute only the latest changes. I always execute the entire sql script after each change during development

fkierzek wrote:
I don't agree about adding [en] to resources. Not all store owners want this behavior. What if they will forget to update the new locale resources after upgrading to the latest version. All I can suggest you now is modifying a SQL upgrade script to not updating existing resources in languages other than English =((