Config file/DB and languages / localization ideas

[urbndecay]

So to start the config setup and the language setup have bothered me forever. Just throwing this out there. These are two things that have bothered me since I first started working on this code base back in 2007 (well not this one, but a version of the BNT code base) and I think they are two issues that should be considered being addressed early on, since they do require touching every file, template, etc. and since we are going to be doing this anyways with the code updates, why not do it now as we go :)

First configuration files.

Currently there are a bunch of configuration files. We have a config (secure and classic, or from the previous version classic and advanced), a DB file, language file, settings file, global defines file, smarty and I'm sure there is stuff in a few more areas.

We then have some of these values loaded into the DB (specifically game settings) which I'm really not sure why because from what I recall most of these values are not manageable from the admin pages (I could be wrong) and I'm guessing some performance hit depending on if the 160+ records are cached.

My suggestion is we switch to the tried and true multi-dimensional array design. It's easy to work with, can be cached with most caching systems, easy to read / edit and is pretty common place. We combine all the settings, configurations, etc. into this file, drop the database config table (gameconfig) and have one common area for managing game/site settings.

You can read more about it here or google for more ideas.

Here is an example

<?php
return array(
    'phpSettings' => array(
        'display_startup_errors' => 1,
        'display_errors'         => 1,
        'error_reporting'        => (E_ALL | E_STRICT)
    ),
    'resources'   => array(
        'frontController' => array(
            'baseUrl'         => '/some/dev/path',
            'throwExceptions' => true
        ),
        'db' => array(
            'params'  => array(
                'host'     => 'localhost',
                'username' => 'foo',
                'password' => 'bar',
                'dbname'   => 'baz'
            )
        )
    )
);

I'm not saying this is the best solution, so if there is better lets do that! For example there is the concept of using a Settings class, but this is really only beneficial to development (IDE autocomplete) and overall worse then the above option.

Second off, languages.

Currently the language support is English, Spanish and French. They were outdated in 2007, and as we move forward they will become more outdated. These days browsers have built in support for language translations, or there are browser plugins/addons, etc. So why bother?

With the current setup we have 1,608 records of words / phrases stored in the database, so that means we have the 3 files to mange as well. It also means any new text we add requires the localization research, adding to the language files, adding to the DB insert file, adding to the DB, and even then chances are we might not even be right with the different languages. It also makes any type of development where text is returned/displayed a pain since each word needs to be looked up.

My suggestion is that we move away from it. Drop multi-language support, get rid of the database, the language files and go 100% English. If we want to support additional languages we do it at the TEMPLATE level which will be much easier to maintain and support. It will also increase performance, development time and get ride of a large outdated maintenance nightmare. Google has great translation support already, and I'm very comfortable with saying we will not do it better then Google.

I know this is going to be a ton of work, and wont happen over night, but is this a direction we would want to go?

[thekabal]

"Currently there are a bunch of configuration files" - There are two. classic_config.ini (which is not secure), and SecureConfig.php. The only reason they are separate from each other is that one holds secure information, while the other does not.

The language file isn't technically a config file, but even if you consider it one, its only one: english.ini. I removed the other languages last year (?) or so after I tried to make a parser to tell me which string/variables were not in the various languages. At 1735 lines right now (and many more yet to be moved into it) I never seriously considered it likely that an admin would be editing it with any real regularity.

Which puts us at just the two. You mentioned the global defines, which is on my list to eliminate. All of the defines are mostly related to logging, and the current logging system needs to be dragged out back and shot ;)

"We then have some of these values loaded into the DB (specifically game settings) which I'm really not sure why because from what I recall most of these values are not manageable from the admin pages" You are 100% correct, but that is a future addition I'm planning. I want to dramatically simplify the settings (228 settings?!!?), and then make them editable in the admin panel.

With those future goals in mind, I'm happy with the current implementation of the two configuration files. I like ini's simplicity, and would rather not migrate from it for the classic_config.ini.

The question about why to keep the language support if we are just using English for the forseeable future is a reasonable one. While there are excellent translation systems available, in fact most barf at the mere mention of exotic concepts like warp drives and sector editing. Having a human hand is superior, and my multi-lingual friends and players have made that clear. Further, from an academic point of view, having the string/language entries in a separate location makes them stand out in an obvious way making it easy to discover places where we have not yet correctly separated them (Traderoutes, scheduler, so many more).

It is indeed a ton of work, and none of those would add much value to either an admin, or a player. While not every major decision meets those criteria, most of the ones I've identified as ones I want to tackle have been:

• Templates add value for both in variety, security, and stability.
• Adodb->PDO gives security and stability.
• PHP7+ compatibility adds speed/responsiveness, and security.

There are surely other major iniatives that are worthwhile to tackle (Routing, DB redesign, PGSQL compatibility, etc), but for now, I'd rather not tackle configs & language changes on a grand scale.