Jump to:
| Project: | Localization client |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
As i see in i18nstrings and l10n_client the current method of identifying source is not that stable.
We ran into issues when special chars where present in source that gets converted.
If source currently contains Newlines the source won't get matched (my tests where with i18nstrings extension) and no save occurs. While the first step to fix this is adding feedback (not saved warning), i'm additionally longing for a more reliable string identification.
I suggest adding a lid (or some general unique identifier) to the item identifier instead of combining it. We still can use traditional locale functions to save (without lid as identifier) after a new clean source load on server.
Thus we're relying on a single unique identifier which makes things more stable (but also extensible).
What do you think?
Comments
#1
FYI: Related patches are:
#688048: Display feedback on submission error
#361147: Support for different text groups
#2
I think this is a very good idea and will prevent other future string-matching issues.
The main problem here is that we are relying on core locale module, which just caches page strings (not lid's) so we don't have that available later unless we query again for lid (for all strings).
I've run into this issue with i18nstrings, and haven't been able to find a good solution (well, overriding the full locale module but that's not a nice one...)