In commerce they do multiply the amount. But in there the multiplier is a setting and I do not think that making it a setting in our case is a way to go. So what i did now is checking the number of digits after the decimal point and cutting off all those that come after the second. Then multiplying it by 100 to make it a whole number.
+++ b/README.txt
@@ -118,8 +118,6 @@ The main features of the core system include:
- A suggestions system that makes recommendations about related content that
could be translated with the same job.
-- Sources can declare which parts of a source text should not be translated,
- for example placeholders for user interface strings.
The following sources are currently supported:
@@ -135,10 +133,6 @@ The following sources are currently supported:
@@ -135,10 +133,6 @@ The following sources are currently supported:
to translate various configuration elements of a site: blocks, terms, fields,
node types, contact categories and many more.
-- Locale
- Allows to translate locale strings. Currently limited to the default
- textgroup (user interface strings passed through t()).
-
Two translators are included in the project:
...
- File translator
Uh, it shouldn't do this? :)
+++ b/controller/tmgmt.controller.remote.inc
@@ -12,12 +12,33 @@
+ /**
+ * {@inheritdoc}
+ */
+ public function save($entity, DatabaseTransaction $transaction = NULL) {
+ /** @var TMGMTRemote $entity */
+ $entity->amount = $entity->getJob()->getTranslatorController()->amountToInt($entity->amount, $entity->currency);
+ return parent::save($entity, $transaction);
+ }
+
...
$entities = parent::load($ids, $conditions);
+ $translator_controller = NULL;
+ /** @var TMGMTRemote $entity */
foreach ($entities as &$entity) {
- if (is_string($entity->remote_data)) {
- $entity->remote_data = unserialize($entity->remote_data);
+ // A possible approach is to load the translator controller for the first
+ // job and reuse it in the following iterations. This can work in most of
+ // the cases as remote mapping entities are usually loaded for a specific
+ // translator. However if we have a case when remote mapping entities are
+ // loaded across different translators, then we might get a wrong
+ // conversion which would be difficult to track down. For that reason we
+ // do load translator controller for each entity.
+ if ($entity->getJob() != FALSE) {
+ $entity->amount = $entity->getJob()->getTranslatorController()->amountToFloat($entity->amount, $entity->currency);
}
Still too much logic :)
tmgmt_remote shouldn't care at all about it. It's an integer, any input must be an integer.
If gengo returns us a float, then we need to convert it there. And then when we display it in the table. No need for new methods on the interface or so. Storage should always be in int.
Okay, so tmgmt core only provides the fields currency and amount. How they are handled it is upon translators.
The interdiff is not that correct, missing update of tmgmt_test and tmgmt.crud.test. However the patch itself is now so small it should not be an issue.
Comments
Comment #1
blueminds commentedHere is a first try. I am not sure about the 100 multiplier, maybe double field?
Comment #3
blueminds commented#1: tmgmt-remote_amount_currency-2112077-1.patch queued for re-testing.
Comment #5
blueminds commentedComment #6
berdirCurrency amounts should never be stored in floats. this could lead to rounding errors.
Currency must always be stored in the smallest available unit for a given currency, see how commerce handles it.
The translator is responsible for formatting the currency.
Just to be sure, maybe make set size to big or so? (not sure what the default is right now).
Comment #7
blueminds commentedIn commerce they do multiply the amount. But in there the multiplier is a setting and I do not think that making it a setting in our case is a way to go. So what i did now is checking the number of digits after the decimal point and cutting off all those that come after the second. Then multiplying it by 100 to make it a whole number.
Comment #9
blueminds commentedMoving the amount transition to translator
Comment #10
berdirUh, it shouldn't do this? :)
Still too much logic :)
tmgmt_remote shouldn't care at all about it. It's an integer, any input must be an integer.
If gengo returns us a float, then we need to convert it there. And then when we display it in the table. No need for new methods on the interface or so. Storage should always be in int.
Comment #11
blueminds commentedOkay, so tmgmt core only provides the fields currency and amount. How they are handled it is upon translators.
The interdiff is not that correct, missing update of tmgmt_test and tmgmt.crud.test. However the patch itself is now so small it should not be an issue.
Comment #13
blueminds commentedThe fail here is fixed by https://drupal.org/comment/8175519#comment-8175519
How do we proceed in such case?
Comment #14
berdirThe easiest thing would be to extract the fix in a separate issue, commit it and then move on.
Comment #15
blueminds commentedHere is the extracted patch: https://drupal.org/node/2136499
Comment #16
berdir11: tmgmt-remote_amount_currency-2112077-5.patch queued for re-testing.
Comment #17
berdirThanks, finally committed and pushed!