I'm seeing a discrepancy regarding the code line references above the msgid when extracting C# code translations. I'm using Linux and two people who are using Windows are getting different line numbers than me. Those two people get the same line number results, so there is a some kind of systematic difference in the extraction process between Linux and Windows.
We extract translations from JSON (with out own extractor module) and from Godot scene files (with a third party module), both of those extract the line numbers consistently. So it is only the JavaScript extractor that is in Babel that for some reason reports different line numbers for the code.
See for example: Revolutionary-Games/Thrive#1914 (comment) where I noticed the problem for the second time.
This is very annoying and causes a lot of unnecessary changes in git commits.
My only guess as to what might be wrong (we already tried requiring BOM in all of our C# files) is that Windows line endings somehow cause the problem, though that'd be a bit weird as I don't see the line numbers doubling which is what I'd expect if the extractor accidentally treated the \n and \r both as new lines.
I'm seeing a discrepancy regarding the code line references above the msgid when extracting C# code translations. I'm using Linux and two people who are using Windows are getting different line numbers than me. Those two people get the same line number results, so there is a some kind of systematic difference in the extraction process between Linux and Windows.
We extract translations from JSON (with out own extractor module) and from Godot scene files (with a third party module), both of those extract the line numbers consistently. So it is only the JavaScript extractor that is in Babel that for some reason reports different line numbers for the code.
See for example: Revolutionary-Games/Thrive#1914 (comment) where I noticed the problem for the second time.
This is very annoying and causes a lot of unnecessary changes in git commits.
My only guess as to what might be wrong (we already tried requiring BOM in all of our C# files) is that Windows line endings somehow cause the problem, though that'd be a bit weird as I don't see the line numbers doubling which is what I'd expect if the extractor accidentally treated the \n and \r both as new lines.