OpenSource-Tools / LiquidVoting

1 stars 0 forks source link

change "issue" to "goal" and "initiative" to "proposal" #54

Closed kvdmolen closed 9 years ago

kvdmolen commented 9 years ago

I have no idea how much impact this might have on integrity, but let's say that only on the outside, we'd like to change the identification of an issue to a goal, and initiative to proposal

this will make the whole app much more understandable.

textual it's not that difficult i guess if we ctrl-f-replace all in the locale-files.

just a bit worried about the URL structure. how difficult would that be?

nktc commented 9 years ago

Making this change globally would be a huge job.

There are over 2000 mentions of the word "initiative" in the frontend code.

If we really need to do this then we can but I think we would want to set up a separate instance of the site for testing.

On Thu, Apr 16, 2015 at 5:27 PM, Klaas van der Molen < notifications@github.com> wrote:

I have no idea how much impact this might have on integrity, but let's say that only on the outside, we'd like to change the identification of an issue to a goal, and initiative to proposal

this will make the whole app much more understandable.

textual it's not that difficult i guess if we ctrl-f-replace all in the locale-files.

just a bit worried about the URL structure. how difficult would that be?

— Reply to this email directly or view it on GitHub https://github.com/Socioneers/LiquidVoting/issues/54.

kvdmolen commented 9 years ago

ok, understand.

Though, my hypothesis is that if we change the EN locale-file from:

["Add a new competing initiative to issue"] = false;

to

["Add a new competing initiative to issue"] = "Add new competing proposal to the goal";

that this would change the text throughout the interface, right? That would be something we can do ourselves. Also for the Georgian translation that is easiest.

URL structure we'll leave for now, indeed too dangerous and time-consuming..

nktc commented 9 years ago

Editing the translations file will not cause it to be changed throughout the interface. The locale file is a list of key => value pairs.

You add string text in the interface files, like this:

_("Key")

_ is a function which passes its argument to the translation file. If it has the key, it returns the translated result. So an example:

Suppose there is a lua script sidebar file that has this text:

ui.container{ content = _("Birthday") }

When the system is run, if the local is EN, it will print "Birthday." If on the other hand the locale is DE, it will print "Geburtstag".

Now, let's say you want to change "Birthday" to "Anniversary". You would need to make the change in the lua script file, the English locale file, and the German locale file. This is because the word "Birthday" is the common key holding all of these together.

Make sense?

kvdmolen commented 9 years ago

Yes, makes perfect sense, thanks!

But still, my logic was that the EN file states = false:

["key"] = false;

leading to the assumption that the _ function checks if the value is false or not. If false, use key, if not false, use value. So then changing this in EN locale file to:

["key"] = "value";

will work.. no? try?

nktc commented 9 years ago

Yes, this type of override works. see here, left hand side for an example: http://178.62.254.91/lf/issue/show/4.html

kvdmolen commented 9 years ago

Super! we can deal with that from here, there are quite a few lines that can be improved..

Thanks for checking