Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> Does "--sort-by-file" really mean that? >> >> The option is documented to sort output by file location, but does >> it mean without the option (i.e. default), there is no guarantee in >> the output order? Or are we sure that the output is sorted by the >> order of input files, and that is guaranteed to hold in the future? >> >> If we are depending on certain ordering of the output produced by >> gettext suite of programs, I would keep the option, regardless of >> what we do to the input to them, if I were running the i18n part of >> this project. >> >> But I am not, so I would not complain if --sort-by-file is dropped >> against my advice ;-) > > The gettext docs are pretty light on the subject, but the default "sort > order" is none at all. I.e. it'll just inhale source and spew out > translations in the order you feed them to xgettext. > > So in order of input files, and then in order they're seen in the > program. > > I don't think that's ever going to change. OK, so as long as make's notion of $(sort) and gettext suite's notion of --sort-by-file are the same, we didn't make any change, and even if they were different, since there is no version of Git that uses "--sort-by-file" while preparing the po and pot files, it still is OK. As long as make's $(sort) is as stable as gettext suite's "--sort-by-file" across developer locales (and our filenames are ascii-only and hopefully will stay that way), everybody will get the messages in the same order either way (or we would have the same problem so switching from --sort-by-file to $(sort) is not making anything worse).
