This patch should fix all currently untranslatable strings.

This patch is build against DRUPAL-5.

CommentFileSizeAuthor
#4 og_translatability_bugs_D5_2008051102.patch58.78 KBhass
#3 og_translatability_bugs_D6_2008051101.patch81.33 KBhass
og_translatability_bugs_2008051101.patch31.25 KBhass

Comments

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Needs work

i mentioned it before - those views strings make little sense to translate. they will end up using the language of the user who was active when cache was rebuilt. earl has an open discussion going about translation of views.

please patch against 6 as well.

hass’s picture

hass commented

I remember you wrote something about a caching issue (http://drupal.org/node/240478#comment-820932) and you wished it get a WON'T FIX, but Earl said he have always cached the views data by language (http://drupal.org/node/240478#comment-820948)... I'm not sure if you are right here or not, but i hope Earl knows best.

Earl haven't refused this patches - are you going to refuse the above patch as is!? I'm little bit lost about views and caching issues...

As i understand you above "code needs work" for the D6 patch or something else?

hass’s picture

hass commented
StatusFileSize
new og_translatability_bugs_D6_2008051101.patch81.33 KB

Attached a D6 patch after a more deeper code review that contains much more changes to get things better for future.

hass’s picture

hass commented
Status: Needs work » Needs review
StatusFileSize
new og_translatability_bugs_D5_2008051102.patch58.78 KB

And a new D5 version. It is smaller while i haven't wasted my time on minor double to single quote changes as I've done in D6 version.

Aside coder.module should run on OG... there is much to do on code style and trailing spaces.

hass’s picture

hass commented

Are there any issues with the patches?

moshe weitzman’s picture

moshe weitzman commented
Version: 5.x-7.1 » master
Status: Needs review » Needs work

So, that begs the question of why there is no t() around strings when you export from Views? All these Views changes are just going to get overridden when I re-export. I refer to the D6 patch, specifically.

merlinofchaos’s picture

merlinofchaos commented

Views caches by language, so translating strings default views is recommended. Now, you still lose the translation when the view is overridden, but it's better than not translating at all.

hass’s picture

hass commented
Status: Needs work » Needs review

If someone overwrites the view files and does not insert the t()'s back it's his own fault - not OG's. So setting back to CNR as the patch seem to be correct. Thank you.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Needs work

That someone is going to be me. I work on these Views by constantly making changes and exporting them to code. I don't yet understand why Views export does not add t() itself.

hass’s picture

hass commented

Hm - what about leaving the views part outside for now and add the t'ified strings back later, when you are finished.

In parallel we could file a feature request in views queue to t'ify strings automatically in the views generator!? See #262879: Exports: t'ify view templates by default

merlinofchaos’s picture

merlinofchaos commented

Views export doesn't add the t()s itself because when I went to do that, I discovered that it's a little bit difficult to identify where the t() needs to go from code. Remember, lots of it ends up being exported via var_export.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs work » Fixed

I applied this to 5 and 6 (except default Views, since those are in flux for 6)

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.