Crispy wrote
I am not sure why you think this should change. You can change much of this by simply changing the resx files. In most places such as all core elements you should use the same wording for consistancy. Now, on the module level I see good reason but the framework already handles this via resx files per module.
I can see a core method being added, perhaps, that handles if one should show update or add, but even this can be handled on the module level.
Chris,
most (unfortunately not all) modules use the resource keys cmdCancel.Text, cmdUpdate.Text and cmdBack.Text from /App_GlobalResources/SharedResources, and I support this, as it reliefs translators from unnecessary redundancy and guarantees consistency all over the portal.
What I was heading at, is not a technical question, but more a semantical, as sometimes cancel should be back - e.g. in user roles: if you select a role and assign users, the link at the bottom is "cancel" - this implies imho, that assignment changes are taken back, but in facts the changes are already store in the database, so "back" would be a more suitable command. There are other examples in 3rd party modules, that deal with more complex logic than the original core modules - and this leads to custom solutions as "update", "cancel" and "update and back" (seen in MLAnnouncements by Apollo Software), when it is suitable to save and continue with the current view. This derives from the fact, that "update" means in most cases "save and exit" - the difficulty arises, if you need a "save only" action. I ran into this problem during translation, when I tried a slightly different translation for better clearness - that failed occasionally, so I switched back to a direct translation, but I feel still somewhat unsatisfied with it.
I hope, I could make the point a bit more clear - and sorry for hijacking this forum.
Sebastian