Duplicate entries in dart file

[zreptil]

when running generate_from_arb there are duplicated entries in the resulting dart files. I think this is because i defined the same translation and variable in different source-files. But i think this should be handled by the translation-generator.

in my current project i have the following code in different html-template-files:
file 1:
<ng-container @i18n="title of settings">Einstellungen
file2:
<none @i18n="title for settings dialog">Einstellungen

In the dart file there are these entries:
"Einstellungen" : MessageLookupByLibrary.simpleMessage("Einstellungen"),
"Einstellungen" : MessageLookupByLibrary.simpleMessage("Einstellungen"),

[BANG88]

Someone can fix this problem. Thanks 😭

[alan-knight]

I think this might be more complicated than that. Having duplicate messages is supposed to be a warning. Although I tried to reproduce this in the tests, and I ended up having neither message included in the output, which is also undesirable.

But more generally, two messages with the same text don't necessarily translate the same way, particularly if they have different descriptions. For example (this actually happened) is we can have a calendar widget with short names of days of the week across the top. There are better ways to do this than using translations, but if we did
shortSaturday() => Intl.message('S', desc: 'Saturday');
shortSunday() => Intl.message('S', desc: 'Sunday');
and these got collapsed into one message, it would not be good.

[BANG88]

This happened when you or your workmates defined two intl in many place but we don't know.

[zreptil]

The problem with the same messages that may be better translated to different messages in foreign languages is true, but it is another problem than this here.

The core problem is, that the string itself is taken as a key in an associative array, where the keys have to be unique. No programming language can handle duplicate keys in such an array. I am also aware of the advantages that this method brings the programmer. He just has to put a simple call to a function in the code and everything is working. With other keys he would have to remember the key and give it to the function, which will be much more uncomfortable.

Meanwhile i solved the problem for my purposes in this way: After creating the files with intl_translation:generate_from_arb i run a batch file that simply scans the produced output and removes every line that is found more than once from the file. It was a little tricky to do this under windows, but thanks to the internet i found a solution.

Using this solution and having now a perfect working translation makes me think, that it should be possible that this step is done within intl_translation after creating the file and before writing the file to the drive. It doesn't remove the lines that just have the same key, but different translations, since the lines would not be the same. so this case would still create a file that cannot be compiled. But for the very common case that there are same messages in different locations that have the same meaning this would enhance the usability a lot.

[alan-knight]

That's fair. Do you have a simple repro for this? I tried to write one, and for some reason I wasn't getting it. Ideally, in the form of a change to the tests :-) But those tests are kind of painful to debug.

[pak3nuh]

Hi @alan-knight
I see that dart-archive/intl_translation#60 fixes this but it has been closed without being merged.
Are we going to get a different PR that fixes the issue?

@zreptil I did a different approach. When I run the script generate_from_arb.dart I only feed one of the dart files that contain the message ids. In my project, this works because those files are checked by the compiler and they will contain the full range of keys.

[alan-knight]

I am no longer involved in maintaining this package. The source of truth for this package is in the internal Google repository, so PRs don't get merged directly, but incorporated there and then a new version is released. However, there have been several versions released since that was closed, so if it was merged I would expect the problem to be fixed by now.

[mosuem]

I agree with @alan-knight that silently removing the keys is not the right solution, this should produce a warning.