If a field is marked as translatable in its definition, no matter if it is configurable or not, it will be offered up for translatability configuration in the content language settings, participate in translation forms accordingly, and it will be properly stored (given that you implement a multilingual entity schema as explained in https://drupal.org/node/1722906).
To mark non-configurable fields as supporting translatability, call FieldDefinitionInterface::setTranslatable(TRUE), like in Node:
public static function baseFieldDefinitions(EntityTypeInterface $entity_type) {
// ...
$fields['title'] = BaseFieldDefinition::create('string')
->setLabel(t('Title'))
// ..
->setTranslatable(TRUE)
);
// ...
return $properties;
}
This does not in itself make the title translatable, it just informs the system that it can be made translatable. Then the content translatability configuration (admin/config/regional/content-language) exposes this on the user interface which allows administrators to actually mark the field translatable.
The entity base fields identified by the following entity keys plus language cannot vary per-language though:
iduuidrevision idbundle
In fact any attempt to provide or alter their definitions to make them translatable now causes an exception to be thrown.