Hi,
 
I am about to upgrade and will yet again need to alter all the static messages I have changed. (FOR 2 SITES )
 
I cannot simply save the previous file which contains these messages and overwrite the new one as I have been informed there are lots of new static messageS in the latest release.
 
So could we not have a system where when changing a static message we get the option to place the custom message in a folder which the system checks first and if the message is not in that folder it uses the main folder.
 
In the same way the templates system works.
 
Or alternatively could these be database driven perhaps, with unique id numbers that do not change preserving the message part through each upgrade as new static message could be appended to the new table somehow.
 
Ideas please.
 
Or if anybody has good workaround already please let me know !

This is an issue.
 
I move all the modified messages to the bottom of the file so, at least I know what I have changed.
BUT - I still have to carefully modify each new file on upgrade!!!
 
Chris
 
 
btw - I was attracted to this thread for "better static massage management"

I agree. I'm in on this one for sure!

I have not done an upgrade so have not encountered this problem. But I will do an upgrade shortly.
 
So if in doing an upgrade modified static messages go missing and they all have to be done again, I support the campaign to get have ViArt provide better static message management.

I've done some upgrades.
 
I've got this promlem especially in the unique hungarian language files, that needed to update in every update manually.
 
The lang file's definitions grouped by modules, and if a new def is inserted I need to manually search for differences (in total commander Compare files by content).
 
Could be very useful to place new defs to the bottom of the lang files:
 
/// Viart 3.6.8 New Definitions
Def 1
Def 2...
 
And list the deleted ones:
/// Viart 3.6.8 Deleted Definitions
// Def 21
// Def 69
 
In this way We will be able to easily translate the new defs, and "find and replace" (by nothing) the deleted ones.
 
The template sys is a bigger problem. I have no idea, but respect the Campaign!!!

I'd have to agree that this section needs to be reworked, I'm working with the english version and from what I've seen some of the entries must have not been created (or even reviewed) by a native language speaker.
 
As an example the "User Login" section has the words "You login as" which is bad in so many ways...
 
As it stands we have to update the message files not just for changes in function but also to fix non-standard English.
 
Having the messages appear to be so badly worded makes you look like a 3rd world based company.
 
The admin sections have the same problem, here is a message from one of those screens : "This schema could be work for each mailbox"

Whilst the business is British, the programmers are not.
 
They are really good and very helpful people but I agree, as an Englishman, that the language used does need attention.
 
The same goes for the accounting terms used - they are not standardized.
 
I have made many changes to language but would like to find the time for a complete overhaul.
 
Chris

One tip that stops overwriting amended language files is to copy the language folders being used to an unused two letter language code.
 
For example copy the "messages/en/" folder (English) to "messages/gb/" and alter these files for your British English messages ie "postcode" instead of "zip", "delivery instead of "shipping" etc..
 
You then set the language code in the static tables to point to the new two letters used and use [gb]..[/gb] codes to define the language areas in multi-language texts.
 
When ViArt is upgraded you simply compare the new "en" folder with the "gb" one and copy across any new definitions as the "gb" folder hasn't been overwritten.
 
However this is tinkering - we still need a global solution - http://www.viart.com/php_modification.html refers.

It would work, Ned, but whichever way we do it there is always the need to go through the file comparison process.
 
More tedious when you are using more than one language as I do!
 
Working with language files in the same way as template files is all we need
 
Chris

Another application I use does this by writing changes to a second language file. The app loads lang1 file, then lang2 file, variables defined in lang 2 overwrite variables loaded from lang1.
 
When a new version is released, it does not have the store owner's lang2 file, so as long as all the strings have the same name, all the customized messages are preserved.
 
Real simple.

Wazoodle,
Yes this system is used by carts such as opensoution and works very well, one file "chaining" another.
 
I explored this when this topic came up but unfortunately in PHP it appears you can't redefine a definition and the VIArt messages are written as "define(....);"'s - not as variables - which throws an error when you try and redefine.
 
Hence my suggesting a user prefix for amended PHP files - unless ViArt rewrites the messages contents as variables.
 

I have had this reply from Viart
 
 
What we would like to add it's some kind of indicator to each constant when the message was added like
define("CONSTANT", "constant"); // 3.5
We think it can simplify work with new constants.
 
Your thoughts please !

However, the 3.5 would need to be the first thing in the line, because then you can sort it by that.
 
Or have it xml or something where you can edit it in an excel sheet.

I dont see the merit of this Im afraid. All it does is tell us if new messages have been added and at what version.
 
I see two courses of action.
In the first suggestion:
The Define messages are changed to variables by ViArt.
The "messages.php" file loads a second "user_messages.php" file _if present_ where the variable messages are overwritten if needed.
The messages file then changes the variables to definitions if that how ViArt need to work with them.
 
The advantages of this system is that the "user_messages.php" file isn't distributed and therefore not overwritten on upgrade. Non technical users dont have to change anything.
The disadvantage is that you have to check your "user_messages.php" file against upgrades to see if the syntax has changed and you need to change user messages or add further ones.
 
The second suggestion:
ViArt add the user prefix switch to look for all changed PHP files as Ive suggested elsewhere - http://www.viart.com/php_modification.html
The messages stay as definitions.
The messages file is copied as "user_messages.php" and changed by the user.
 
The advantages of this solution is that theres less work by ViArt and the "user_messages.php" file isn't distributed and not overwritten on upgrade. The huge benefit is that _any_ php file can be changed.
The disadvantage is that comparison and addition on upgrade is still required.
 
The second solution has, in my view, more benefit than the first because of its global implications.