*They* be dragons, so let's leave it at that.

I think this calls for creating separate package(s) and a small script which will take user input from the command line like translate.pl --infile 'xyz' --outfile 'aaa' --verbose 1. I said maybe more packages because what I see above is some app-specific functions like http_tiny (I would call that fetch_from_server or something?) and also some more general-purpose functions like get_secrets which is general because it reads a config file and looks for some user-specified keys and, therefore, you can reuse that for other apps you will be creating in the future.

More concretely, app-specific functions go to (say) Net::API::DeepL and general-purpose go to Aldebaran::Util. Now that's a first thought, other Monks may have some better suggestions. But the gist is to separate code in packages, and aim at re-using code (e.g. from your Aldebaran::Util) for any other scripts you produce in the future.

Once you have these packages, then you create the simplest script to "drive" them and here useful will be Getopt::Long which makes it easy-peasy to parse CLI user input (the --infile xxx above).

If you are still with me, then you need to start this properly:

Module::Starter provides the CLI command module-starter which creates a skeleton project/app directory: module-starter --module='Net::API::DeepL' --builder='ExtUtils::MakeMaker' --author='Aldebaran' (optionally add --email=xyz@... if you want to publish this and get feedback, perhaps CPAN).

Note, I have always used ExtUtils::MakeMaker, disclaimer: I never tried the alternatives, as this covers my needs just fine.

Now you have a dir Net-API-DeepL and in there there will be your main file lib/Net/API/DeepL.pm. It will have a skeleton pod and be ready for inserting your subs in there (those related to DeepL and not those general ones). So add one sub in there (like the tiny_http).

Your immediate next step will be to create test(s) for testing that sub you just added. Well, the wise ones will say that your first step is creating the test and then creating your tiny_http()!

Create file t/10-tiny_http.t which may contain (just a suggestion):

#!/usr/bin/env perl
use strict;
use warnings;

use utf8; # if you must

our $VERSION = '0.01';

use Test::More;
use Test2::Plugin::UTF8; # rids of the Wide Character in TAP message!

use Net::API::DeepL qw/http_tiny/; # import our new module

my $results = http_tiny(...);
# this is how a test looks like:
ok(defined $results, "http_tiny() : called and got defined results");
ok(ref($results) eq 'HASH', "http_tiny() : results is a HASHref");
# etc etc etc

done_testing(); # epilogue
[download]

And you are ready to test your module:

perl Makefile.PL
make all
make test
[download]

You can create other test files for different subs, don't stuff everything into one test file. All test files will be run automatically with make test (and in alphabetical order, that's why we prepend them with numbers).

Once your subs are tested, then create the driver script. This will be your main entry to Net::API::DeepL from the command line. E.g. translate.pl --infile ...

Here is a skeleton which demonstrates the use of Getopt::Long to parse CLI parameters.

#!/usr/bin/env perl
use strict;
use warnings;
use utf8;
use Getopt::Long;

use Net::API::DeepL qw/http_tiny/; # import our new module

my ($infile, $outfile, $verbose);
$verbose = 0;
if( ! Getopt::Long::GetOptions(
  'infile=s' => \$infile,
  'outfile=s' => \$outfile,
  'verbose=i' => \$verbose,
  'help' => sub { print STDERR "Usage : $0 --infile xx --outfile xx [-
+-verbose N]\n"; exit(0) },
) ){ die "error, something wrong with the command-line parameters." }

die "parameters needed!" unless $infile and $outfile;

my $results = http_tiny($infile, $outfile, ...);
# at this point consider adding all your parameters into a hash and
# pass that to http_tiny($options) instead of passing a long list whic
+h
# may contain optional parameters.
die unless $results;

print "$0 : done, success.\n";
[download]

Well, that's something to get you started: create project dir, add module functionality, create tests, create driver script. I have omitted more details on file lib/Net/API/DeepL.pm like how to export http_tiny(). Will do that when you are ready.

Also, you may want to think about creating a database of past translations which your module fills in as data is fetched from server so that you don't translate things twice. But with free text translation this is not going to be worth.

Edit: Also, you may want to consider using an OO approach. This allows for storing some data into your translate object (of class Net::API::DeepL), e.g. your credentials. If you need to be doing multiple translations, this will be ideal:

my $config = get_secrets();
my $trans = Net::API::DeepL->new($config);
my @results;
for my $totranslate (@$translations){
  push @results, $trans->http_tiny($totranslate);
}
[download]

Others may want to give their advice or make a comment for all I mentioned above as nothing is written on stone, please do.

bw, bliako

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.