the submoule i18nstrings of i18n should be integrated for state translation (optionally)

Comments

broon’s picture

broon
Location Potsdam
commented

In theory, this shouldn't be too hard. In fact, by calling function i18nstrings($name, $string, $langcode = NULL) if i18n is installed any dynamic string is translateable. But in order too make string ids more generic we should extend the states table by an unique id (& primary index) and this id should be used internally to check permissions, set states, etc.
Otherwise things would get really messed up.

gold’s picture

gold
they/them
Location 20 minutes in the future
commented
Version: 6.x-1.2 » 6.x-1.9

The next update I'll add for review will include t() everywhere.

It also includes configurable live/none states so all states are now editable by the site owner. Hopefully that will suffice for this purpose.

eugenmayer’s picture

eugenmayer commented

Gold, that change with "none" and and live configureable should be reviewed _very_ closely and iam absolutely not for taking them in into the next release. There are a lot of special cases to cover AFAIR, eventhough making those to configureable make sense.
We have on issue right now, and thats the missing "label". none and live are also "keys", and important ones. You cant simply change the key currently, you rather should change the label.

gold’s picture

gold
they/them
Location 20 minutes in the future
commented
Status: Active » Closed (works as designed)

Yep. found the issue with them being keys. Have worked around it though.

Also realised that my comment here didn't really apply after reading another post regarding i18nstrings. Missed that i18nstrings was a contrib module.

Actually this could be rolled into the other issue which, from memory, was relagated to a submodule should anyone chose to write it. Will close this one for now.

If anyone wants this please see i18n: keep the tnid links between revisions intact and contribute a sub module.