Vim clone left "dirty" after make. src/po/ru.cp1251.po is modified. #14490
Comments
|
Hmm, interesting! Do you have this happen sometimes, and always on this file? Can you please tell me what your gettext is? Version and so on... |
I see it every month or two
Not sure, maybe. For reference, take a look at https://groups.google.com/g/vim_dev/c/Gyqie6FQM4s/m/W2yZLzsuAwAJ from December, other people see this once and a while.
I built with current source this morning. |
|
Okay, thank you! |
|
Based on this line |
|
I have also been bothered by this and i ended up just compiling with I will take as an example commit 8fcc129 because it is the more recent one, but it could be any commit that updates the translation files. To reproduce:
notice how ru.po timestamp is newer by a few MS
Explanation:
This is possible for any translation file that uses iconv, listed in here. |
I didn't know what you meant by |
Yeah, that's what I was thinking. But not "iconv", but on "msgmerge" and text formatting.
In my opinion, this is too small a difference to handle the rule. Anyway, according to the documentation, for "nmake.exe " the accuracy is a 2‐second interval. Thank you for your explanations. |
|
BTW, I use popOS, I update regularly. So I guess their distribution hasn't incorporated the 0.22 version. |
|
I switched to version 0.22 and use it when preparing translations. Anyway, I'll try to figure out what's going on. |
Probably it would have been simpler to to force the “newer” timestamp (for reproduction; your method is nice to explain how Git might leave the timestamps in an unexpected state). |
Right, I wanted to show how this could be triggered just by using a simple git pull, without any special modification on the .po file itself. But for a fast reproduction a simple I debugged this a bit more and now i think know for sure what is happening:
You can verify that by using Right now Thus there are three fixes required:
(3) is technically not required if (1,2) are fixed because the output will always be the same, but still worth fixing it so we don't waste time regenerating those files. I hope this helps! |
|
If All of (or most of) the other po files are wrapped in 80 columns. So, I think |
|
Hm, so we should add a check to check.vim. Something like this: " Check that all lines are no longer than 80 chars
let overlong = search('\%>80v', 'n')
if overlong > 0
echomsg "Lines should be wrapped at 80 columns"
if error == 0
let error = overlong
endif
endifInterestingly, I checked this against de.po and got a match. So there is something I need to fix for German as well. |
Problem: Overlong translation files may cause repo to become "dirty"
Solution: Add a test into check.vim to warn for lines being longer than
80 virt columns
related: #14490
Signed-off-by: Christian Brabandt <cb@256bit.org>
Overlong translation files may cause repo to become "dirty"
Problem: Overlong translation files may cause repo to become "dirty"
Solution: Add a test into check.vim to warn for lines being longer than
80 virt columns
related: vim/vim#14490
vim/vim@6f585da
Co-authored-by: Christian Brabandt <cb@256bit.org>
By default, when Vim is built, PO files in the "src/po" directory are processed. If you don't need this, you can use this command: This will cut through the PO file processing and does not require you to change
When checking on the host and stand systems, no big differences in time stamps
Unfortunately, that doesn't always happen. The illustration below shows the file created by
The difference in formatting between "ru.po" and "ru.cp1251.po" is probably
Also, the check revealed that almost all PO files have different text The illustrations below show the difference in formatting between the original msgmerge --width=79 The following was done to utilize uniform text formatting:
No influence on text formatting from the "iconv" program and its analog from Hopefully, these steps will help eliminate unplanned processing of PO files.
It might be worth using the "msgconv" tool in the Makefile too. Pros:
Cons:
(The ability to use "iconv" if necessary will of course be retained) |
Yeah sorry, i was wrong here. This was simply a wild guess I made because had no idea that windows makefiles may use
This 1-second timestamp interval must be specific to your system and not how This excellent explanation by the maintainer of GNU make may clear up some confusion: https://lists.gnu.org/archive/html/help-make/2001-04/msg00047.html |
It needed to be verified one way or another and it's good that you brought it to
Thanks for the links to useful descriptions of how the make program works. |
Steps to reproduce
I occasionally see this, and I think I've seen mention of this on the dev list; it might always be the same file; this morning I happened to catch it just after it happened. I also built yesterday morning. It doesn't happen too often (the revert file I see is from January), I haven't looked at makefiles, I don't know what dependency is triggering.
If anyone knows something specific to check...
After pull, make reconfig, the console shows the make ending as:
The diff seems to be a lot of formatting. Here's an excerpt, as seen in vim.
It interesting that the wrap, as shown in vim above, is happening right around column 80. With all these formatting changes it's hard to see if there are any real changes.
Using
gvim -dto look at the checked in file and the it looks like the only changes are around the linebreak and that the translation itself has no changes.Expected behaviour
No modified checked-in file.
Version of Vim
9.1.0299
Environment
ubuntu/gtk
Logs and stack traces
No response
The text was updated successfully, but these errors were encountered: