{"action":"created","issue":{"url":"https://api.github.com/repos/freeorion/freeorion/issues/223","labels_url":"https://api.github.com/repos/freeorion/freeorion/issues/223/labels{/name}","comments_url":"https://api.github.com/repos/freeorion/freeorion/issues/223/comments","events_url":"https://api.github.com/repos/freeorion/freeorion/issues/223/events","html_url":"https://github.com/freeorion/freeorion/pull/223","id":95804985,"number":223,"title":"Parser adjustments and reorganization of functional settings in stringtables","user":{"login":"Dilvish-fo","id":10995939,"avatar_url":"https://avatars.githubusercontent.com/u/10995939?v=3","gravatar_id":"","url":"https://api.github.com/users/Dilvish-fo","html_url":"https://github.com/Dilvish-fo","followers_url":"https://api.github.com/users/Dilvish-fo/followers","following_url":"https://api.github.com/users/Dilvish-fo/following{/other_user}","gists_url":"https://api.github.com/users/Dilvish-fo/gists{/gist_id}","starred_url":"https://api.github.com/users/Dilvish-fo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Dilvish-fo/subscriptions","organizations_url":"https://api.github.com/users/Dilvish-fo/orgs","repos_url":"https://api.github.com/users/Dilvish-fo/repos","events_url":"https://api.github.com/users/Dilvish-fo/events{/privacy}","received_events_url":"https://api.github.com/users/Dilvish-fo/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-07-18T08:51:45Z","updated_at":"2015-07-18T16:34:10Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/freeorion/freeorion/pulls/223","html_url":"https://github.com/freeorion/freeorion/pull/223","diff_url":"https://github.com/freeorion/freeorion/pull/223.diff","patch_url":"https://github.com/freeorion/freeorion/pull/223.patch"},"body":"For a long time now, something like this has been on my mind because of the complications that functional stringtable entries cause for our translators (and then sometimes from their resulting mistakes).  Also, in PR #213 @geoffthemedio  and @Vezzra had concerns about the settings being stored in config.xml, and Vezzra suggested that the settings for it should instead be in a content-directory global_settings.txt, and so...\r\n\r\n* made parse::file_substitution() less promiscuous in it's search for includes; specifically, prior to this they could start anywhere in a line and therefor could not be commented-out.  This requires that they be at the start of a line and preceded by a single '#', as in\r\n#include \"shared_macros.txt\"\r\n\r\n* made Stringtable use parse::read_file instead of it's own identical version, and also use parse::file_substitution, so that the functional, non-translatable stringtable entries can be moved out of the stringtables.\r\n\r\nRemoved functional, non-translatable stringtable entries from being directly present in the stringtables, by incorporating them via the newly supported #include functionality for stringtables. The purpose is to minimize translator confusion and risk from translator mistake and to facilitate customization.  The functional entries were divided into three groups.\r\n\r\n * The first group is in default/global_settings.txt.  This will be for more general settings & it may be useful in the future to have the server specify them for the clients.  This contains no currently functional setting entries, but has placeholders for the production queue frontloading and topping up factors.\r\n\r\n * The second group is in default/content_specific_parameters.txt.  This is primarily for content specific entries that are used to determine various aspects of the UI, such as which tags get used for the Census popup, and which specials count as Growth specials for the purposes of the ObjectListWnd. If content customizations are made to these aspects of content then the player will likely want to make corresponding changes to these entries.\r\n\r\n* The third group is in default/customizations/common_user_customizations.  This is for again for entries that affect the UI, but unlike the content-specific settings, these are more a matter of personal preference, and the players is somewhat encouraged to customize these to their preference.  THe current sole entry is that controlling the order of Sitrep presentation in the Sitrep panel."},"comment":{"url":"https://api.github.com/repos/freeorion/freeorion/issues/comments/122562585","html_url":"https://github.com/freeorion/freeorion/pull/223#issuecomment-122562585","issue_url":"https://api.github.com/repos/freeorion/freeorion/issues/223","id":122562585,"user":{"login":"Dilvish-fo","id":10995939,"avatar_url":"https://avatars.githubusercontent.com/u/10995939?v=3","gravatar_id":"","url":"https://api.github.com/users/Dilvish-fo","html_url":"https://github.com/Dilvish-fo","followers_url":"https://api.github.com/users/Dilvish-fo/followers","following_url":"https://api.github.com/users/Dilvish-fo/following{/other_user}","gists_url":"https://api.github.com/users/Dilvish-fo/gists{/gist_id}","starred_url":"https://api.github.com/users/Dilvish-fo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Dilvish-fo/subscriptions","organizations_url":"https://api.github.com/users/Dilvish-fo/orgs","repos_url":"https://api.github.com/users/Dilvish-fo/repos","events_url":"https://api.github.com/users/Dilvish-fo/events{/privacy}","received_events_url":"https://api.github.com/users/Dilvish-fo/received_events","type":"User","site_admin":false},"created_at":"2015-07-18T16:34:09Z","updated_at":"2015-07-18T16:34:09Z","body":"@adrianbroher Please note that this was already an add-on from a different task.  For such things I tend to take the shortest reasonable path that is a clear improvement accomplishing my goals without significant drawbacks.  This may not be your preferred solution, but it is a reasonable path that accomplishes my goals and appears to me to be a clear improvement.  The most significant drawback I can think of is that we should probably preface these functional keys with \"FUNCTIONAL_\" and then include a warning at the top of the stringtable that in order to avoid potential key conflicts with functional entries, no stringtable keys should begin with \"FUNCTIONAL_\".\r\n\r\nI suppose it would be a fairly moderate additional step to make new ParameterString(keyword) and a ParameterStringList(keyword) functions based off the the UserString ones but reading from a parameters.txt file (which would itself incorporate these same subfiles) instead of a stringtable.  Were you trying to make an encouraging suggestion of adding that further improvement to this initial improvement?  I am rather tight on time no, though, so I don't want to make commitments there is no compelling reason for.  It appears to me that this would be fine as a later extension of this work; stopping here for now creates no problems for the later extension.\r\n"}}