i would remove the spaces

why making it protected ? IT should be private IMO

@OskarStark The purpose is for translation software when presented with a file to know that Symfony generated it. Knowing this means the software can process it differently to how it might by default. I could elaborate on that, but in general if a file format provides a generator declaration, I see no reason not to use it. Also other projects using the Translation component may have their own requirement for declaring themselves.

@stof making the method private is fine for the Symfony case, but I was under the impression that Components were supposed to be portable. As shown in the test case, a supposed XliffExtendedFileDumper sets its own tool signature, hence why I made it protected.

@timwhitlock we start with marking methods private and only open them if someone with a good use case asks for it.

@timwhitlock making things protected is generally the worse extension point ever (it hurts maintenance a lot because we need to maintain BC on them). It is better to design proper extension point where needed than allowing to hack into the internal logic by exposing it. Inheritance is most of the time not the proper extension point.

I tend to agree with @stof, instead of introducing a new method here we can override those value via $options

As per my initial comment I thought the maintainers would prefer to decide on best practice. I'm not experienced in contributing to Symfony, as evidenced by this discussion. If anyone maintaining the Translation component is interested in implementing this properly then great. Either way, feel free to close my PR. I'm afraid I don't have the time to rework it.

@timwhitlock no worry, we are here to work together :)