Pending 4.15.1 release

[falkoner]

Hi Paul, I am pretty sure that the file names, and line numbers are for reference purposes only and do not get compiled into the .mo files.

It was the line wrap stuff that was concerning me, as I think that was what Rafael was striving to stop. It seems you have it sorted

Tim

[falkoner]

Hi Paul, I am pretty sure that the file names, and line numbers are for reference purposes only and do not get compiled into the .mo files.

It was the line wrap stuff that was concerning me, as I think that was what Rafael was striving to stop. It seems you have it sorted

Tim

Paul, I notice that Rafael has committed changes to the translation files, but to the master branch rather than the release branch. This concerns me because:
1 The new translation strings aren't in the release, and
2 This will cause you a big headache when you come to merge the release branch back into master.

Tim

[TurboPT]

That's exactly what I've been fighting this week. (kind of what I elaborated on the other day)

I'll update the make_release (to align to most of what Rafael's script has) and see how the strings look in the po files. The only other difference that we'll have afterwards is that make_release has the --no-wrap with msgmerge commands and his script does not. Since the translation was done on master, the GLTransInquiry file line references are off by a few lines.

Looking at some of the master PO files, the strings are split on multiple lines, which I thought that Raphael did not want to see?
I've not yet seen an email response, but I'd like to really get the release done this weekend, as this language matter is the only thing remaining. If necessary, I might have to revert his master commit so that I can re-run the language file on the branch to merge.

Anyway, will see how it goes tomorrow.

[falkoner]

If necessary, I might have to revert his master commit so that I can re-run the language file on the branch to merge.

This is a problem with not using Git/Github as it is meant to be used. We are trying to force a distributed version control system to behave as a centralised version control system, and in the process losing most of the advantages of a DVCS.

Nobody should be pushing directly to the webERP-team repository, they should be pushing to their own repository and then issuing a pull request to webERP-team. That way the commit can be reviewed before it ends up in the main line, where it has to be reversed out in a clumsy way if it is wrong.

[TurboPT]

Ok, well I can avoid doing that, seemed to be the easiest way to go. (probably a horrid shortcut, perhaps)

Anyway, foregoing any other suggestions, I'll still align the language build commands and then rebuild again, at least some of the diffs should go away. As long as the strings are exactly the same, I'll keep the strings that are not split across multiple lines.

[falkoner]

I agree Paul, let's just go for it.

Github provides a way of enforcing pull requests for main repositories but it is always best if these things can be done voluntarily. It is after all a volunteer project.