[SalesForce] Batch Apex that does DML and multiple callouts

I'm not sure you will be able to solve that issue in an interactive context. You might have to use something like Batch Apex or Future methods to get around it. I have had a similar issue with Mixed DML and overcame it using Batch Apex.

So, firstly, I created a simple interface

public interface IAction 
{
    void process(BatchJob job);
}

Then, I created a couple of work classes to do the work for each type of action:

public class FolderCreator implements IAction
{
   public void process( BatchJob job )
   {
        // inject some state here and do the business
   }
}

public class CustomSettingUpdater implements IAction
   public void process( BatchJob job )
   {
        // inject some state here and do the business
   }
}

Then, in your start method of your Batch Apex, build up a list of IActions, for example

List<IAction> actions = new List<IAction>();
actions.add( new FolderCreator() );
actions.add( new CustomSettingsUpdater() );

Then, set your batch size to 1 and iterate over the actions thus isolating each action from one another, e.g..

for( IAction action : (List<IAction>)scope )
{
    action.process(job);
}

Not ideal having to use Batch Apex when really I didn't want to but it worked for me.

I would recommend you use a pattern discussed in the 3rd Edition of Dan Appleman's Book Advanced Apex Programming. You mention using a custom object. I'm presuming you're saving articles to the custom object when you want to send them out for translation. That would work especially well for this pattern.

The pattern would have you use a trigger on the custom object. The trigger would save a record to a 2nd custom object with the recordId, and a few other details you'd want to have for the purposes of error handling as files are processed by your class, plus sent and retrieved from your web services. Let's call the 2nd object DataMonitor.

When the record is saved to the DataMonitor object. An After Insert trigger would fire that will call a queueable provided there are sufficient limits available for it to call it (queued at time <5 & no more than 100 jobs on hold in flex queue, plus under org limits for async apex). If there aren't, it will check to see if it can request a schedulable job instead (limit of 100 in org at a time plus under org limits for async apex). If it can call the queueable, the queueable will query for records in DataMonitor. If it finds any, it will retrieve what it can process (only one if that's what you say it can handle, more if that's possible). Similar would happen with the schedulable.

From there it will make the web services call out. If it's successful at initiating the callouts, it will write-back a success message to the records it sent; marking them as having been sent. If you wish, it can also send you an email with the results (check email limits first). Finally, if there are more records remaining and limits available, it can call another queuable to process them. If there isn't room in the queue, it could alternatively schedule another Schedulable to do them at a later time depending on the kind of limits available.

This is something of an "industrial strength" pattern in that it provides the ability to retry sending records if the first attempt isn't successful. If, after a couple attempt, or after receiving a recognizable error type, you can choose to write back the error to the DataMonitor record and also send the email to the Admin with some kind of special notation on it, so they'll know they need to take action. I believe this pattern is discussed in Chapter 7 of Dan's book.