i18n is only supported for user interface translations - not supported for customizable text fields

This is still the case with the current versions. In Drupal 7 i18n_variable seems to be responsible for that but it seems to be unable to configure forward's variables to be translated …

This is definitely not by design. I just don't think full content translation was ever taken into account at any point during the module's history. Will look into what it would take to support it.

John

I just saw that the variables are indeed passed through t() and are translateable via the interface translation - which is not optimal but at least doable. The problem is that those are not translateable via http://localize.drupal.org because the strings are variables …

IMHO this is what needs to be done:

1. Use hook_variable_group_info() to define a new variable group.
2. Use hook_variable_info() to document all variables used by forward.
3. Cleanup the the usage of t() and variable_get() to be consistent. (ie. don't use t(variable_get(…)) …)

I've created a simple start to integration with the variable module. This also makes some user customisable field translatable.
It adds a new file forward.variable.inc to the module root dir.

I would like to translate the e-mail message that is sent so if it is send from say a Russian site the e-mail will appear in Russian.
Is this possible now? If not is there an email module that does have multi-lingual support?
I'm not sure where this bug is holding.
Thanks

I also would like to translate the text of the form:
Thank you for your interest in spreading the word about
NOTE: We only request your email address so that the person you are recommending the page to knows that you wanted them to see it, and that it is not junk mail. We do not capture any email address.
Your Email

etc...
how do I do this?

I never got a chance to look at this problem in depth. I am guessing it would be a fairly major update. The D8 version of Forward will need to support full multilingual - interface AND content - out of the box in its first release. I will look at D7 again but this would be a good area to have someone else jump in and help.

Is the patch in #6 a working fix?

I believe it's working, but it is only a partial solution.

I'm able to translate interface elements and get nodes forwarded using the appropriate language for that page. I am not seeing the issues presented in this thread. If you can post a link to your site I can take a look. Guidelines:

* You won't see strings within the Translate Interface admin until you browse to the Forward page in the language you want to translate to. For example, a Spanish site might have a URL of http://site.com/es/forward?path=node/34

* Assuming that node/34 is the Spanish version of the node, the forwarded content will be in Spanish. This is using the Entity Translation model.

The 8.x branch includes the necessary schema so that configuration text can be translated into other languages. Drupal now auto generates the form pages that are needed as long as the proper YAML files are setup, which has been done for 8.x.

Doesn't that mean that the 8.x needs a port to 7.x?

Multi-lingual is totally different in 7.x, so a true "port" for an issue like this one isn't really feasible. We could make multi-lingual in 7.x better, but it wouldn't be based on anything in 8.x.

Entity translation for the content fields works okay, but the variables set in the module are not translatable.
I've started work on 1 and 2 from comment #5. Cleaning up the t()'s is still work to be done.

Too bad a back port is out of the question. But I'd rather not dismiss this issue completely.
Also, this issue never dealt with 8.x. So it is either a "won't fix" for 7.x or "needs work". Don't you agree @john.oltman?

Issue queues can be managed in different ways, and there is definitely precedent for marking something as Fixed even if you have to upgrade to get the fix. That said, if you are doing active development on this issue we can certainly change status.