Coverage decreased (-0.4%) to 96.517% when pulling 3ae062d on Daimler:multilang_descriptions into 173ba03 on eerimoq:master.

the test coverage should include the missing lines once the ARXML-3 patch is in. I will add it to the ARXML-4 files if you want, but this would slightly delay things for the rest of this series...

the last revions had some serious issues, sorry for that. The new one fixes this.

It's not obvious to me how this should be designed. Suppose you have an ARXML-file with comments in german (no english) which you want to convert to a DBC-file. With the logic in the PR the DBC-file would not contain any comments as only None and EN are checked when using .comment (which the DBC dump function does). I would expect the DBC-file to have comments in german. Converting from DBC to ARXML (which is not currently supported) would have similar problems.

One alternative design is to add a language argument to all classes and functions that need to know the language in use. By default it would probably be english (EN). All file formats without language information would gladly accept the language choice. Only file formats like ARXML would actually use the language. This would allow loading a DBC-file with comments in german to generate an ARXML with "DE" comments (given that the user passes language='DE' when loading the DBC-file).

.comment is in the selected language. .comments is a dictionary of comments in all available languages.

I suppose that the root of this problem is that the capabiities of DBC file format and ARXML are not identical for our purposes. I agree that converting all internal code to always use a dictionary when it comes to comments would do the trick, as far as I can see. For the ARXML-to-DBC converter, I also see this the same as you: One could have specify the language which ought to be used in the DBC externally and let the .comment attribute default to something reasonable (e.g., 'EN' if multiple languages are defined, and the only element in the dictionary if the dictionary size is one)? The question then becomes: What's a good default policy?

BTW: Do you happen know why coveralls again claims that the overall coverage is down, but if you inspect the results, coverage for all individual files is equal or increased? (maybe I just misinterpret its results)

No, I do not know why the coverage is down again =)

We don't need any default policy, the language is known with Message(..., language='EN') if we go for that design. language='EN' has to be added in lots of functions and classes, but that should be fine.

ok, let's do it this way then. later?

Sure, let's postpone it if it makes things easier for you.

could you please press The Green Button? (it probably is grey ATM, though ;)

thanks :)

I actually meant to postpone the whole PR, but let's just redesign it later (probably before a new release).

I actually meant to postpone the whole PR, but let's just redesign it later (probably before a new release).

+1. For my current goal (i.e., proper support for Daimler-style ARXML-3 CAN description files), this is just a side concern, though. That said, I'll help with proper internationalization support where I can.

What's special with Daimler ARXML-files? Will other companies/users still be able to use cantools? I certainly hope so.

What's special with Daimler ARXML-files?

not much. They are basically just standard ARXML-3 files but they use a lot of features, and use a weird XML namespace.

So far all of my PRs equally applied to ARXML-4...

i.e., xmllint says they validate against the AUTOSAR 3.2 XSD which I found in the internet after changing the namespace.

Great, you certainly add much value to the ARXML module, and if it's close enough to the standard it should be easy to support the general case as well if someone asks for it/implements it.