New strings

New strings Started by Jorin · April 21, 2015, 06:55:17 am · Read 15332 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic - Topic derived from Changes to language strings

New strings

April 21, 2015, 06:55:17 am

Is there a rule where to add a new text string into a language file?

Re: New strings

Reply #1 – April 21, 2015, 07:59:57 am

hmm... it's quite a general question.
Are you talking about a string to use in Elk "as a general" (i.e. the package distribute), or a string that you need in your installation? Or maybe something else?
In the first case... I'd say common sense (i.e. depending on where you need it there may be places better suited).
In the second case I'd suggest to use the Addons.{language}.php file, since this one is meant for extending the language strings without having to fear the strings are lost during upgrades.
In the third case... I guess some more context may help giving you a better answer.

Re: New strings

Reply #2 – April 21, 2015, 06:45:31 pm

Use a separate language file and include that file

Re: New strings

Reply #3 – April 22, 2015, 01:17:15 am

Quote from: emanuele – April 21, 2015, 07:59:57 amIn the third case... I guess some more context may help giving you a better answer.

I thought about optimizing the translations. If we could use a way to "organize" new strings inside the language files we wouldn't need transifex any more. A way could be to seperate new strings from the old ones and then list the deleted ones (compared to the previous version of the file), all inside the file itself. What do you think?

Code: [Select]

string a
string b
/*new strings with ElkArte 1.0.4*/
string c
string d
/*deleted strings witth ElkArte 1.0.4*/
string e

With the deleted strings only the difference to the previous file should be listed. To keep it clean.

Re: New strings

Reply #4 – April 24, 2015, 12:46:53 pm

Ohh... now it's clear what you mean!

That may really be a good way to organize strings while updating, just to have some "easy" tracking.
The potential drawback I see is that "in the future" these strings would either remain in a place they do not belong to (just because for example a string added should stay together with another bunch defined somewhere else) or we'd have to remember before a major/minor release to move them in the "correct" place.
No hard feelings either way.

Unless there are objections I guess we can at least try in the next releases.