Hi @all,
I'd really appreciate if the features module would be able add the correct context to translatables.
An example:
If you have the i18n_field and i18n_string modules installed, all field strings get contexts (e.g. "field_name:node_type:label" for the field label). If you now extract a translation template with potx, the feature module does not provide this context... and so an automated update of your translation catalog is not possible and you have to update all strings manually.
What do you think? Should the features module use/provide these contexts?
I'd appreciate your feedback
Thanx in advance & cheers
hctom
Comments
Comment #1
hctomHmmm... am I the only one who has this problem, or didn't anybody ever read this issue?!
Comment #2
j.muschalle CreditAttribution: j.muschalle commentedHi!
I have the same problem too and I created this patch to fix it. It adds context in the t() function when label and description of field are exported.
Comment #3
colanComment #4
j.muschalle CreditAttribution: j.muschalle commentedLittle misstake about context name of a field.
Here the new patch
Comment #5
hefox CreditAttribution: hefox commentedWhat's the reason for removing the array_unique?
Tab characters? Coding standards in general.
Coding standard (spaces) + why need array_push here?
Comment #6
j.muschalle CreditAttribution: j.muschalle commentedHere, the new version of the patch.
For the unique array, I did a little helper function to have a unique multi array, maybe you have a better solution.
I don't know why I used array_push, I changed that! :)
For the tab, I resaved my patch with my no configurate gedit, sorry, I changed that too!
Comment #7
j.muschalle CreditAttribution: j.muschalle commentedHere, the new version of the patch.
For the unique array, I did a little helper function to have a unique multi array, maybe you have a better solution.
I don't know why I used array_push, I changed that! :)
For the tab, I resaved my patch with my no configurate gedit, sorry, I changed that too!
Comment #8
j.muschalle CreditAttribution: j.muschalle commentedComment #9
cedric CreditAttribution: cedric commentedThe patch in #7 works fine but the code is a little weird, especially the part that filters the array of translatables.
I re-rolled it and used a simpler approach of generating the t() calls in an array of strings, and then I filter duplicate lines.
ALSO: My patch adds support for translatables for the 'allowed values' of a select box. This could be a separate issue, but since allowed_values also need a special context, it is easier to do it in a single patch.
Comment #10
Johnny vd Laar CreditAttribution: Johnny vd Laar commentedThe code in the last patch works but perhaps there should be a check whether the allowed values have empty labels or not. I've added that in the patch.
Comment #11
Tess BakkerHere is the patch for Features 2, based on the #10 patch.
Comment #12
hefox CreditAttribution: hefox commentedthe first changes contain some coding issues, should likely run it through coder
Comment #13
mpotter CreditAttribution: mpotter commentedSeems like this also generates the header comment text even if there aren't any translatables.
Comment #14
Johnny vd Laar CreditAttribution: Johnny vd Laar commentedAttached is a patch that fixes a bug in translating descriptions and fixes the coding style errors.
Comment #16
Johnny vd Laar CreditAttribution: Johnny vd Laar commentedHmm I can't seem to find anything wrong with my patch. Anyone with a clue?
Comment #17
Johnny vd Laar CreditAttribution: Johnny vd Laar commentedAnother try then ;-)
Comment #19
Johnny vd Laar CreditAttribution: Johnny vd Laar commentedGah
Comment #19.0
Johnny vd Laar CreditAttribution: Johnny vd Laar commentedJust formatting the text and fixing minor typos
Comment #20
Johnny vd Laar CreditAttribution: Johnny vd Laar commentedWhat else is needed to get this included?
Comment #21
BoobaaWorks for me, thanks. Hopefully it'll get in soon!
Comment #22
hefox CreditAttribution: hefox commentedSorry just looking over this briefly, would this break any current translations of the items with added context?
Comment #23
mikran CreditAttribution: mikran commentedCurrent translations just don't work when textgroup is anything but 'default'.
But t() (with context) is not how i18n_strings are translated so would this even work? Potx would produce a file with default translations mixed with translations with contexts but those would still be default translations, right? How would the import process go to separate the strings into different text groups?
Comment #24
cedric CreditAttribution: cedric commented@mikran : You are right that by itself this patch is not enough.
You also need to patch the string export and import modules so the context and textgroup is preserved the whole way around.
In our case, we are using the potx module to export translations which we patched and we use l10n_update to re-import which we also patched.
So for us a total of 3 patches was requires to get everything to 'work'.