Feature Request: Centralize core output strings

Description of the suggested feature and how it is supposed to work for the admin/end user:

The suggested feature is to move hard-coded output strings (things like “Portal has disconnected” or “Lockstring error”) out from the respective modules and into new modules strings.py in each subpackage of the Evennia library. The strings.py module would look as follows (example from the objects subpackage):

models_db_player_help_text = 'a Player connected to this object, if any.'
models_db_sessid_help_text='csv list of session ids of connected Player, if any.'
# ...
models_set_location_runtimeerror='Error: {self}.location = {destination} creates a location loop.'

… and so on. So, the string named according to an ordered schema. The proposed schema here is modulename_<unique_name> but it could also be formalized to modulename_classname_funcname_varname (although this feels very cumbersome to actually use). The string in question should have formatting markers for use with the format() method of strings. In objects.models, this string would then be used like this:

from evennia.objects import strings
# ...
except Exception, e:
       errmsg = strings.models_set_location_runtimerror.format(self=self.key, location=location)
       logger.log_errmsg(errmsg)
       raise

Finally, there should be a mechanism for easily overloading named strings from the game-dir. This could be something as simple as a module custom_core_strings.py in server/conf where users can specify a given string (they are responsible for adding the correct formatting markers) which will then overload the core version at server start. Each subpackage strings just does import * from this module as their last actiont their ends, which will overload matching strings with custom ones (the details of this is not clear yet).

A list of arguments for why you think this new feature should be included in Evennia:

1. The current core strings are today completely hard-coded into the core library of Evennia. Some of these do occationally appear for the end-user too. Currently for a developer to override them requires to either to manually hack the library core or to find the ones who are under i18n and write a custom language file for them. The first is hackish and something we really don’t recommend for maintainability reasons. The latter works but for those who don’t want to actually change the language but just change some phrasing this is hardly intuitive.
   1. The ability to overload core strings via a settings file means it’s a lot easier for developers to customize the strings and also for core devs to track the available messages (maybe introduce some more string-reuse).
2. Concerning string-reuse there could also be a “central” strings module (directly under evennia that other strings modules could pull from - these would be common phrases and error messages used repeatedly. This would make it easier to customize in one place (if these are imported into each sub-strings module, then they could still be overloaded on a per-subpackage form if desired - maybe.
3. It would allows us to completely centralize internationalization. The strings modules could be run through i18n in one go, grabbing all strings at the same time. It would make it easy to know what was currently covered or not.
4. Converting to using .format() string formatting not only makes strings compliant with i18n (some languages just puts things in a different order), it is also a small step towards cleaner py3 compliance.

Extra information, such as requirements or ideas on implementation:

Note that this feature does NOT cover the changing of strings in user-modifiable modules, like Typeclasses, Commands and Lockfuncs. This is only for core strings in modules that the user is not supposed to otherwise touch. Other modules already have mechanism for how to customize them, and introducing this system there would just make them harder to read.

Even though making the mechanical system behind it (allowing for overloading, batch-applying i18n) is probably not too hard.

The main work here (once the system is in place) is to convert all existing strings to use the centralized strings modules with proper formatting - that means that for every string:

1. Check if an existing string variable can be re-used
2. If not, copy the string to the proper strings module and convert it to use {format} statements and give it a suitable variable name.
3. Replace the current position in the main module with the variable and use .format() as applicable.
4. Test.

This is one of those projects that many people can be involved in, also people with little Python exprience - it’s not hard, just a lot of work.

[carenajosh]

Do you really want to call it strings.py?

[Griatch]

@strikaco I don’t think there was ever any doubt that i18n could be used for this purpose. I will stand by the fact that it’s not its intended usage and that relying on it in that way is not ideal. It’s just likely better than any alternative (breaking out strings into separate modules or reworking every little bit of core to be pluggable just for the purpose of changing a string).