i18nstrings l10n_client support

If you follow the link you'll see an actual patch

Oh :-(

I thought people reads the module description before the code :-)

http://drupal.org/project/i18n

Jose, I confirmed the text group patch for l10n_client.
However support in i18nstrings is not complete.

You've built l10n_client_add_string_to_page into i18nstrings_tt() but it's still missing in i18nstrings_ts().
I have no idea why, but i18ncontent e.g. explicitly calls i18nstrings_ts for content_type->help text.
Thus the help text never shows up in l10n client.

So this patch is needed to extend l10n support for ts too.
(BTW: Will you be able to explain me why the content_type->help code is so strange?)

As i see there's sometimes $source missing - for your code and for the new one.
In case of active l10n_client i've added a new line to always be sure $source is loaded.
This way my l10n client works perfectly. Without, many text group information is wrong (empty).

Anyway l10n client needs another patch update. Going to submit my solution ASAP.

There was still a wrong case in _ts. if no string was provided source was always shown empty.

Note that in current latest version the api changed.
See:
http://drupal.org/node/789286

For i18nstrings() this is ported correctly.
i18nstrings_ts() misses l10n_client support.

For i18nstrings_text() the functionality of l10n_client is still missing.
Does l10n_client have support for a input format based translation? (will it store the result correctly?)

Note: Some remaining documentations need cleanup in i18nstrings. I'll try to do so.

I'm a little confused now why i18nstrings (and i18nstrings_ts) and i18nstrings_text act so different.
If i18nstrings has corresponding functions _update and _delete... Why is the _text function not part of the i18nstrings() itself? Why is i18nstrings_text() not documented as API in file header?
Why does it load so differently (no context, ...)?

What happens if a format based string gets requested via i18nstrings? Will it even miss check_plain?

We need to clean this resulting situation up.

Just to mention i18nstrings_text() would need checking access to input filters so that strings cannot be just added to l10n client. I suggest we let this ones for later as it would need a bigger and more complex patch.

Also I'm not sure the 'textgroup' support is up to date. Anyway, the patch looks good so if you tested it with latest l10n_client, please go ahead and commit.

I have done some rewriting on the i18nstrings_ts() and i18nstrings_text() to for integration with l10n_client.

Attached a tiny updated version to review.

For the next iteration we should add a static cache to decide earlyer if the l10n code complexity is needed.
There's a lot of code that currently gets executed and all requested strings get stored in l10n client even if it is disabled. Adding a static cache will solve many issues.

Looks good. Committed.

Agree about the static cache, for next version.

For now it will be easier to test and debug without caching. So I think we can focus on performance improvements for next version.

Reworked a little bit, see i18nstrings_add_l10n_client() Also fixed some flawed logic in previous code for checking the format.

Still, it seems there's something wrong with strings saved by l10n_client. We used to form_alter the l10n_client form to handle submission for other textgroups than default, I wonder whether it is still appropiate or we don't need it anymore

Switching to 'active' as this needs some more testing and bumpint to (release) critical.

Fixed one more issue. It seems when translation is missing we need to pass TRUE as the translation for it to work (Just to be consistent with locale strings).

About overriding and saving l10n strings, the problem with l10n_client is that if we have a source string twice for a textgroup (because there are two strings that are the same), it just updates one. So we still need to override that saving ajax callback

In my latest tests everything seems to be working. Getting ready for a new i18n release.