[ENH] Added translations

[horstoeko]

[ENH] Added translations
[BRCH] Breaking Change in ZugferdVisualizerMarkupRendererContract

Description

An option has been added that allows texts, codes to be translated into readable text

Type of change

• New feature (non-breaking change which adds functionality)

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

  ZugferdVisualizerMarkupRendererContractgot a new parameter translator

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Several unit tests

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[horstoeko]

Hi @mokraemer,

Please review this PR... Thank you very much. Documentation is following

Kind regards

[mokraemer]

This looks quite wired to me.

• The defult template now has many things missing, e.g. formating the numbers, as I already included.
• The default template formats numbers in d.m.Y which should be handled by the translator, as this is only common in some spaces. even in Germany I format all dates in DIN format as Y-m-d
• Using <?= should be used in mixed content parts, as it is more readable and always enabled since PHP 5.4
• Unitcodes are missing in the "new" translation
• the "new" template misses many fields that are required in invoices! Please review some common available invoices and try to read it - comments, packing information, seller (in case of incomming invoices), payment terms (sepa) is missing.
• I don't see why array's should work better in translations, than decicated methods, which don't give any structure.
• still default template contains php code and should be named accordingly

[mokraemer]

I guess you like to use this class for generating a pdf, which then can be merged with the xml file (zugferd).
But as said, there are some essential fields missing in the output. And this class could be used to view incomming invoices.
My suggestion was, to have a default template, which will show almost everything which could be relevant for common invoices and have e.g. another class which will remove some fields for outgoing invoices as the content is preprinted on the paper it is put to (e.g. seller address).

[horstoeko]

Hi @mokraemer,

Okay. Then unfortunately the work was for nothing....

the "new" template misses many fields that are required in invoices! Please review some common available invoices and try to read it - comments, packing information, seller (in case of incomming invoices), payment terms (sepa) is missing.

Okay. I'll take another look at your template.

My suggestion was, to have a default template.

Why not using different template files... This is already possible...

I don't see why array's should work better in translations, than decicated methods, which don't give any structure.

I find such hard-coded things as you have suggested simply awful - that's how software was developed 30 years ago... :-) This always means additional effort to update these things. You must also not forget that a new release would be due every time

[mokraemer]

Hi @mokraemer,

Okay. Then unfortunately the work was for nothing....

the "new" template misses many fields that are required in invoices! Please review some common available invoices and try to read it - comments, packing information, seller (in case of incomming invoices), payment terms (sepa) is missing.

Okay. I'll take another look at your template.

My suggestion was, to have a default template.

Why not using different template files... This is already possible...
Sure, I know - I just said, we should have a general file which inlcudes most of the fields and, if th8is matches more your needs and you want to include it as well, have a more differentiated file for that.

I don't see why array's should work better in translations, than decicated methods, which don't give any structure.

I find such hard-coded things as you have suggested simply awful - that's how software was developed 30 years ago... :-) This always means additional effort to update these things. You must also not forget that a new release would be due every time
I think it depends on what to translate. I preferred having dedicated methods for fixed fields from the xml, and translating regular text the other way around. By using inheritance you can override single translations without doing the whole effort. But I guess there is no "right way" to do it. You could at least define/use constants/enums for typo issues.

[mokraemer]

another thing is, having functions and backed-enums (in a later release) prevents you looking up the key in the wrong context, e.g. invoice types in units.

[horstoeko]

Hi @mokraemer,

Okay. How do we stay now? Would it be better for you to implement your own template that contains the logic you need? Or can you be satisfied with that?