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
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

Dave Reid - June 12, 2009 - 05:51

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

hctom - June 12, 2009 - 08:50

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

Gábor Hojtsy - June 12, 2009 - 10:18

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

hctom - June 12, 2009 - 11:29

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

Gábor Hojtsy - June 12, 2009 - 11:31

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

hctom - June 12, 2009 - 12:12

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

Dave Reid - June 12, 2009 - 13:24

@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

hctom - June 12, 2009 - 13:34

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

Dave Reid - June 12, 2009 - 13:39

The strings from test files do not show up in my local interface. Are you sure about that?

#10

hctom - June 12, 2009 - 14:30

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

Dave Reid - August 22, 2009 - 20:45
Status:active» won't fix

Marking this as won't fix.

 
 

Drupal is a registered trademark of Dries Buytaert.