Enable parsing of .test-files
hctom - June 4, 2009 - 13:33
| Project: | Translation template extractor |
| Version: | 6.x-2.2 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Jump to:
Description
Hi,
I just found out, that .test-files are not parsed by potx so far.
As far as I see, only line 1152 of potx.inc needs to be changed from
$extensions = array('php', 'inc', 'module', 'engine', 'theme', 'install', 'info', 'profile');to
$extensions = array('test', 'php', 'inc', 'module', 'engine', 'theme', 'install', 'info', 'profile');(See the new array item 'test').
Would you be so kind to add this to the code?
Thanx in advance & cheers
hctom

#1
No no no. .test files are often filled with very developer-oriented strings and should not be translated, even though we have a habit of using t(). This is the example that core has established.
#2
I'm not really sure what you wanted to say with your last sentence :-) Should t() not be used within tests? I just looked at core tests in the Drupal CVS and they also use the t() function quite often.
On my opinion, I don't understand why these strings should not be translated. I mean developers do also speak different languages, so why don't present the test results in their language? :-)
And even if they are not gathered for the .pot files, they will show up in the locale interface... so why not adding them to the .pot directly?
Cheers
hctom
#3
I think t() is supposed to be supported if the test looks for things like t('Your %stuff was created', array('%stuff' => ...)). We could assume that these strings were already in the module, so it might not need to be extracted from the test, but can we assume this at all times?
#4
I guess you can't assume these strings are already used in the module... especially for unit tests were you create data to test your functional units...
Cheers
hctom
#5
Well, the data you create would not use t(), I assume. The point of using t() would be to click the right buttons and look for the right data on localized sites.
#6
Sorry... I did not expressed that well :-)
I wanted to say that when you build your unit test case with different test methods, you use assert-messages like t('Created %data.') or something like t('Testing whatever.')... And these strings, I suppose, won't show up somewhere else in the module.
Cheers
hctom
#7
@hctom/6: Yeah, that's the point. When I extract the translation template for my module, if I were to include the .test file, it would add over a thousand new strings that never get exposed to any of the users of the module. I had talked with webchick about this in #drupal a while back and we had both agreed that for the best, the .test files should not be extracted for translation.
#8
Oh okay... now I understand... but unfortunately this is not really a nice solution as the string will show up in the locale interface... so I think the only solution would be to not use t() like in hook_schema().
But this has to be changed in all core tests...
Cheers
hctom
#9
The strings from test files do not show up in my local interface. Are you sure about that?
#10
You are right Dave... I totally forgot, that when the strings are written to the locale tables, the destination is a prefixed set of tables, that is deleted after the tests have run... so they will never show up in the original site's locale interface...
My bad :-) Cheers
hctom
#11
Marking this as won't fix.