No bother - these translating issues are often more complicated then it seems, and there definitely are some issues :-)
Using the TextCollectorTask just like that, will have it try and create new languagefiles for the entire framework/cms. I don't suppose you want that anyway, so it's better to do it on a per-module base. This works fine for any custom modules you want to translate and you'll find that you won't need PHPUnit at all:
http://mydomain/dev/tasks/i18nTextCollectorTask/?module=mymodule
This will try and create a lang/en_US.php file in your module so make sure it's writable! Next you translate that file by making a nl_NL.php copy and replace all en_US occurences in it by nl_NL. That's it!
One somewhat irritating issue: if you try to collect module=mysite, it will result in an error, because for no seemingly valid reason SilverStripe wants to add the Page singularname/pluralname translations to the sapphire/lang/en_US.php file, that (lucky for you) isn't writable, else it would overwrite the file with just these two items. To solve this you need to override the SiteTree provideI18nEntities() methods in your Page class.
Finally, you can always create languagefiles by hand and skip the TextCollector entirely... :-)
Why PHPUnit anyhow?
For Silverstripe to collect text from classes, it seems to need to instantiate them. Working the sapphire module, it then stumbles upon a class like CliTestReporter.php, that wants the PHPUnit. Hence the demand for PHPUnit, which the TextCollector itself doesn't use at all...