Yes, WinMerge translation file naming isn't good and we can improve it. * we need to have consistent naming and less places for translatable files, not more.
Translators have already problems finding correct files and most don't even bother finding all of them. it can't invent yet another way to name translated files. And indeed I'm working with a script to handle version numbering. We should think of ways to make it easier. And making it even more complex is not an option. Which means way too many errors for people compiling WinMerge. WinMerge building is already way too complex. Maybe we should start using revision number for POT and PO files. What happens when I build WinMerge - SVN status says I have two missing files in that folder - those status files. That kind of state files don't belong to version control. I think this patch can be applied to trunk.
What then?īut as a first step, for integrating the feature and testing, it sounds good idea to have it in menu. When should they be used and opened? And hmmm, it is possible to have plain text file in other side and binary file in other side (same file having totally different content in different folders). Perhaps we could ask user first still.Īnother thing is how we want (text) file compare's binary file viewing and this binary file merge relate to each other. And even then this is a bit of hidden in the menu.įrom user's perspective I'd open files automatically to binary compare if we determine files are binary files. Full compare method tells user if files are binary files, but other compare methods don't, so how user knows to use this binary file compare? Probably only after first trying normal text compare. I'm not sure if the sub-menu is a correct place to add this. Now, conceptually I think this is a good idea and I like it. And can you please fix tabs in previous line in menu item too. Only real comment I have for code changes is that please don't add tabs to Merge.rc. DirDoc/DirView changes look good an straightforward.
0 kommentar(er)
