This is:

- [x] a bug report

What is the expected behavior?

In an native excel, the =PPMT (rate, per, nper, pv, [fv], [type]) function allows rate parameter to be a negative value.

What is the current behavior?

The changes added in this commit/line now trigger error when calculating value of the PPMT function when negative rate value is given to it.

I have to admit that I'm not an expert on what the PPMT function does and how it is meant to be used but we have a lot of excel files from experts in the financial industry and they seem to use a negative rate value in this function which now causes our app to crash.

My proposed solution is to simply remove that one line of validation which will make PHPOffice/PhpSpreadsheet behave consistently with native excel.

Which versions of PhpSpreadsheet and PHP are affected?

Effected PhpSpreadsheet version: 1.18.0 and higher

This is still and issue for us so I created a test excel sheet to demonstrate the problem.

Running this code:

$spreadsheet = IOFactory::load('./hlookup-test.xlsx');
$sheet = $spreadsheet->getSheet(0);
$cellVal = $sheet->getCell('H8')->getCalculatedValue();

On this excel spreadsheet: hlookup-test.xlsx

Results in:

TypeError {#3754
  #message: "Argument 4 passed to PhpOffice\PhpSpreadsheet\Calculation\LookupRef\LookupBase::checkMatch() must be of the type int, string given, called in xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/HLookup.php on line 74"
  #code: 0
  #file: "./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/LookupBase.php"
  #line: 25
  trace: {
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/LookupBase.php:25 { …}
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/HLookup.php:74 { …}
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/HLookup.php:45 { …}
    PhpOffice\PhpSpreadsheet\Calculation\LookupRef\HLookup::lookup() {}
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:4846 { …}
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:3539 { …}
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:3332 { …}
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Cell/Cell.php:259 { …}
    ./src/MyNamespace/Command/TestExcel.php:30 {
      MyNamespace\Command\TestExcel->execute(InputInterface $input, OutputInterface $output): void
      › $sheet = $spreadsheet->getSheet(0);
      › $cellVal = $sheet->getCell('H8')->getCalculatedValue();
      › 
    }

ping @MarkBaker let me know if I should provide any more information ;-)

This is:

- [X] a bug report

What is the expected behavior?

Calling $cell->getCalculatedValue() ($cell is instance of PhpOffice\PhpSpreadsheet\Cell) should work but it fails with the latest master.

What is the current behavior?

After $cell->getCalculatedValue() is called, the program fails with following error:

TypeError : PhpOffice\PhpSpreadsheet\Calculation\LookupRef\LookupBase::checkMatch(): Argument #4 ($rowKey) must be of type int, string given, called in 
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/HLookup.php on line 74
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/LookupBase.php:25
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/HLookup.php:74
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/HLookup.php:45
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:4776
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:3469
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:3262
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Cell/Cell.php:259
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:5192
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:4669
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:3469
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:3262
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Cell/Cell.php:259

Here is the $cell variable value before $cell->getCalculatedValue() is called:

And here are the values from a breakpoint right before the error is triggered at HLookup.php:73, PhpOffice\PhpSpreadsheet\Calculation\LookupRef\HLookup::hLookupSearch()

What are the steps to reproduce?

Unfortunately, I cannot simply share the the excel file that fails because it is from one of our customers but let me know if any more information is needed apart from what was shared above. ;-)

Which versions of PhpSpreadsheet and PHP are affected?

Tested on current master branch with PHP 8.0 and 7.4.

unless @majermi4 wants to open a PR 😉

@welcoMattic: I can have a look on the weekend and see if I can figure something out :) but can't promise anything

it looks like we have to handle language creation from the Provider, like it's done in Lokalise provider.

I'm not sure I get what you mean and how this is related 🤔 The main problem is that the keys pulled from PoEditor provider are indexed by the english (or whatever the main language is) translation instead of the keys that were pushed to PoEditor.

Symfony version(s) affected: 5.3.0-RC1

Description <!-- A clear and concise description of the problem. --> The translation keys pushed to PoEditor translation provider with bin/console translation:push poeditor are not the same as the ones pulled back using bin/console translation:pull poeditor --format yml.

How to reproduce <!-- Code and/or config needed to reproduce the problem. If it's a complex bug, create a "bug reproducer" as explained in: https://symfony.com/doc/current/contributing/code/reproducer.html -->

Create a Symfony project and install symfony/translation with symfony/po-editor-translation-provider.

Configure a poeditor provider and create 2 translation files for locales en and cs in the messages domain.

Run bin/console translation:push poeditor which pushes the translations to Po Editor as it should.

Run bin/console translation:pull poeditor --format yml. The local translation file was updated:

I would expect that nothing should have happened because nothing was changed in Po Editor. Instead, it seems that the pull command uses the english translation as key when it reads data exported from Po Editor.

Possible Solution <!--- Optional: only if you have suggestions on a fix/reason for the bug --> I was able to fix the problem when I replaced this line: $source = isset($attributes['resname']) && $attributes['resname'] ? $attributes['resname'] : $translation->source; with: $source = $attributes['id'];

Additional context <!-- Optional: any other context about the problem: log messages, screenshots, etc. --> In the Po Editor project settings, I have set English as the Default Reference Language.

I'm not sure if it's related to the issue but before I did that, the pull command would respond with these errors: