I am working on assigning context to translation string (ref. http://drupal.org/node/334283). I have a solution of adding context to string as follows:
t('View',array('#context' => 'verb'))
t('View', array('#context' => 'noun'))
Currently, there is no context for any string and anything comes as second parameter in the 't' function is ignored by potx system. I am going through the code in potx.inc it is complex. I want to know how easy or difficult it is to look in the 2nd parameter of t and add an additional field in the template next to msgid to include the context information coming along in the 2nd parameter.
Then I am planning on storing the context information as #verb#View or #noun#View in the locales_source table source field. So in locale_target table it will be stored as #verb#Voir and #noun#Voir for French translation.
Please let me know how easy to make these changes in your code, my solution depends on what is happening at your end. Thanks.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | potx-d6-parsing-for-druapl7.patch | 31.85 KB | gábor hojtsy |
| #4 | D7-context-support.patch | 33.09 KB | gábor hojtsy |
Comments
Comment #1
gábor hojtsyI'm following up on #334283: Add msgctxt-type context to t() Technically it is not a problem for potx to examine the second parameter of t(), but I think the original proposals need more thought.
Comment #2
gábor hojtsyMarking postponed on that issue and providing a better title.
Comment #3
gábor hojtsyImplementing this right now.
Comment #4
gábor hojtsyOk, here is the patch I am committing to the Drupal 7 branch. It does need to change the save callback signature unfortunately and how the data is returned from the save callback, so it will not be straightforward to roll out on the 6.x version without corresponding l10n_server fixups (so that D7 modules can be translated on an l10n_server with context support).
However, this one adds parsing support for finding the 'context' key's value in the $options array on t() and format_plural() in Drupal 7. These are the only two functions which support context, and there were many places, where I needed to say in the code that there is no context support, so the strings get the defualt context (same as the current D7 behavior). If curious of what is not context-aware, just grep the patch for POTX_CONTEXT_NONE and you'll get it.
Updated the test code in potx-cli.php and run the parsing test on that. Looks like working right, correct values are found, when $options is there but no 'context', it is nicely skipped, when context is not a string, a nice error is thrown with explanation (as expected), etc. So committing this right away, and will think more about how can we integrate this to the D6 branch, so l10n_server can be used to translate D7 stuff :)
Comment #5
gábor hojtsyCommitted to the D7 branch.
Comment #6
gábor hojtsyComment #7
gábor hojtsyBackported with this patch to Drupal 6. Same parsing API in potx.inc but defaults on functions are POTX_API_6 not POTX_API_7. Also added requirements check to cross-check my upcoming patch against l10n_community, so the use of the same API is enforced. Opening Drupal-6.x-3.x branch with this new code, since we have an API change which affects co-operating modules.