You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(15) |
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(3) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(3) |
Dec
(1) |
| 2008 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
(5) |
Jul
(4) |
Aug
(6) |
Sep
(12) |
Oct
(2) |
Nov
(1) |
Dec
(3) |
| 2009 |
Jan
(2) |
Feb
(1) |
Mar
(3) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
(17) |
Oct
|
Nov
(2) |
Dec
|
| 2011 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Kimmo V. <ki...@wi...> - 2010-09-12 09:05:45
|
Hi, I know I've been telling past year this won't happen. But after the DLL injection security issue I've started reconsidering releasing one more 2.12.x stable release. There is list in net about vulnerable applications (http://secunia.com/advisories/windows_insecure_library_loading/) and that includes WinMerge. So if we don't do something we get bad reputation and users have to start looking for other programs. The fact is as I've earlier told I don't have VS2003 anymore. So I must update the compiler and runtime environment also. Luckily we went through this already in 2.13.x so we hopefully can deal with it without too much pain. It doesn't make much sense to update to VS2005 runtimes so we will update to VS2008 runtimes. There is a risk in doing this and I really rather avoid it in stable releases. But we have no other options. Next 2.12.x stable won't be a similar stable update release than earlier updates have been. So I'm also bumping the version number to 2.12.10 or something like that. This is also a possibility to add some bug fixes to the release. There are lots of bug fixes done over last year and we can merge some of those also to 2.12.x now. I've no time to look through our changelog and check every commit but if you have fixes in mind you want to see in stable update please tell. Regards, Kimmo |
|
From: Tim G. <ti...@ge...> - 2010-09-05 11:02:14
|
Hi! > So I don't want branch yet. But what we can do is release beta release > from the trunk. And put trunk into "soft freeze" until we create the > release branch. Meaning that no high-risk commits. But we need pretty > good baseline for this so that we don't need those high-risk commits to > fix things. Sounds also like a good idea. We only add bug fixes for current problems and thinks like translation updates. Greetings, Tim |
|
From: Kimmo V. <ki...@wi...> - 2010-09-04 15:30:04
|
Hi, > I am not sure if the Trunk is really in a totally bad state! Look at the > download stats from the last experimental builds: > > * 2.13.13 = 7,189 downloads > * 2.13.12 = 13,341 downloads > * 2.13.11 = 9,513 downloads > > This are much more downloads as in the past (and not only because > 2.13.12 was a time at the front page). So more people test the > experimental builds as in the past. that's what I've been wondering too. There are quite lot of downloads and still no flood of (duplicate) bug reports. So it can't be *that* bad. But then we usually hear about lots of bugs only after the stable release. No matter how many experimental and beta releases we do. >> If we can get some kind of agreement about our current status and what >> is broken we can at least decide what to do. What are bugs/problems we >> are too embarrassed to release? > > Why not create a Branch for 2.14 and create a beta version from there? > We can promote the beta more then usually to get more tester. Then we > get maybe a clearer show on the state. Branch becomes painful after a while with our current SVN setup. You need to apply fixes twice and do decision which patch gets included where. To compile and test from both branches. Etc. Also after a while some parts of the code can diverge so much we need to fix same bug differently in trunk and branch. So branch means quite a lot of additional work and time spent. So I don't want branch yet. But what we can do is release beta release from the trunk. And put trunk into "soft freeze" until we create the release branch. Meaning that no high-risk commits. But we need pretty good baseline for this so that we don't need those high-risk commits to fix things. Regards, Kimmo |
|
From: Tim G. <ti...@ge...> - 2010-09-01 19:34:46
|
Hi! > So what opinion others have? Are we in totally unreleasable state or > perhaps almost releasable? Meaning you could release it for few million > users and put your name on it? I am not sure if the Trunk is really in a totally bad state! Look at the download stats from the last experimental builds: * 2.13.13 = 7,189 downloads * 2.13.12 = 13,341 downloads * 2.13.11 = 9,513 downloads This are much more downloads as in the past (and not only because 2.13.12 was a time at the front page). So more people test the experimental builds as in the past. > If we can get some kind of agreement about our current status and what > is broken we can at least decide what to do. What are bugs/problems we > are too embarrassed to release? Why not create a Branch for 2.14 and create a beta version from there? We can promote the beta more then usually to get more tester. Then we get maybe a clearer show on the state. Greetings, Tim |
|
From: Kimmo V. <ki...@wi...> - 2010-09-01 15:03:12
|
Hi, >> So our option for "fixed" WinMerge would be to release 2.14.x stable >> release. > > It would be also a "we are not dead" sign! :) I know you meant this with humor. But looking at our situation it is not funny at all. Just look at our changelogs and SVN log. There is very little happening for past months. And creating a release requires lots of work from many people. We are releasing software for millions of people to use so it is not something we can take lightly! I know we discussed about this in spring when we decided to start the WinMerge 3 effort. And I've written some forum posts. But the fact is discussions and thinking about subject is not code committed to SVN. Also the current trunk situation is something between totally broken everywhere and working just great depending on who you listen. I've unfortunately lost my own "touch" to the situation so I'm getting very confused about where we are. And so far I've seen very rare objective opinions about this. So what opinion others have? Are we in totally unreleasable state or perhaps almost releasable? Meaning you could release it for few million users and put your name on it? It would be very good to get all the fixes and improvements for users. I'm all for it. But we must have reasonably stable code we are releasing. We cannot make it bug-free or implement everybody's wishes. But it MUST work for majority of people. Not just for couple of developers. If we can get some kind of agreement about our current status and what is broken we can at least decide what to do. What are bugs/problems we are too embarrassed to release? Regards, Kimmo |
|
From: T. G. <ti...@ge...> - 2010-09-01 12:07:24
|
Hi! > So our option for "fixed" WinMerge would be to release 2.14.x stable > release. It would be also a "we are not dead" sign! :) Greetings, Tim ___________________________________ NOCC, http://nocc.sourceforge.net |
|
From: Kimmo V. <ki...@wi...> - 2010-08-31 18:19:55
|
Hi, > It must be a bigger problem, since many IT news sites wrote about the > problem: Seems to be a major f*ckup of MS. The bug reporter gave more details and the vulnerability is in MS VS2003 runtime DLLs! So nothing we can do to fix it. And I doubt MS will update VS2003 runtimes anymore. Our only option for "fix" for 2.12.x would be to update to VS 2005 or VS 2008 runtimes. Which would be quite a pain. I'm not sure we have sorted out the runtimes update for 2.13.x yet. Haven't seen new bug reports against latest experimental but that may not tell much... So it is pretty much out of the question to do the update for "stable" release. So our option for "fixed" WinMerge would be to release 2.14.x stable release. Regards, Kimmo |
|
From: Tim G. <ti...@ge...> - 2010-08-30 18:13:20
|
Hi all! > It is about dynamically loading DLL files. The report doesn't specify > where the problems are but there is link to tool that should show > problematic places? It must be a bigger problem, since many IT news sites wrote about the problem: Microsoft warns of DLL vulnerability in applications http://www.h-online.com/security/news/item/Microsoft-warns-of-DLL-vulnerability-in-applications-1064584.html Microsoft tool for DLL vulnerability interferes with some applications http://www.h-online.com/security/news/item/Microsoft-tool-for-DLL-vulnerability-interferes-with-some-applications-1069540.html Greetings, Tim |
|
From: Kimmo V. <ki...@wi...> - 2010-08-30 15:34:53
|
See bug #3056008 http://winmerge.org/bug/3056008 It is about dynamically loading DLL files. The report doesn't specify where the problems are but there is link to tool that should show problematic places? Like I already commented to bug I have no interest (or even tools) to do new 2.12.x releases. But before release this should be analyzed if there is a real problem... Regards, Kimmo |
|
From: T. G. <ti...@ge...> - 2010-08-04 06:21:31
|
Kimmo Varis wrote: > I just opened link http://winmerge.org/Wiki/Developers from our > homepage [...] and it was also broken. Oh, that must be my fault! :-( I used GZIP compression from PHP for CSS 3 months ago and it seems that I broken so the CSS files from the Wiki. Since I have my FTP account not here at work, I can fix it first at the evening from home... http://bitbucket.org/kimmov/winmerge-web/changeset/c961154fd756 Greetings, Tim ___________________________________ NOCC, http://nocc.sourceforge.net |
|
From: Kimmo V. <ki...@wi...> - 2010-08-03 16:56:47
|
Hi, I just opened link http://winmerge.org/Wiki/Developers from our homepage with Chrome browser and was a bit surprised to see the result. Then I checked the same page with Firefox (3.6.6) and it was also broken. But seems to work with IE 8. Regards, Kimmo |
|
From: Kimmo V. <ki...@wi...> - 2010-08-02 14:22:46
|
Hi,
> I tried to compile the GUI with Qt SDK 4.6.3/Qt Creator 2.0.0 on a
> Windows Vista and XP machine (both 32 bit) and get the following error
> (512 times) in the file xrabply.c:
I tested with Visual Studio in Windows (both VS project and nmake
makefile) and couple of Linux distributions (Ubuntu 10.04 and Fedora 13)
where it worked. But forgot to test in Qt Creator.
The thing with Qt Creator is it is Windows environment but uses MinGW +
GCC as compiler. So when configuring project you need kind of mixed
configuration which is partly Windows configuration and partly GCC
configuration. So configs assuming GCC is Linux are easily failing. Like
in this case.
> invalid suffix "UI64" on integer constant
>
> Did you have an idea?
Yes. I made the PRO files for LibXDiff so that I ran configure in both
Windows and Linux and added produced configure.h and winconfig.h to
project file. So now the Windows (win32) configuration is used which is
not compatible with GCC. But quick hack to get compile working is to
edit ext/libxdiff/libxdiff.pro and replace lines inside "win32" block
with lines from "unix" block. So that win32 block becomes:
win32 {
HEADERS += config.h
DEFINES += HAVE_CONFIG_H
}
This seems to work at least for me...
> Also post as issue to the bitbucket project:
>
> http://bitbucket.org/grimmdp/winmerge/issue/1/invalid-suffix-ui64-on-integer-constant
Thanks, I'll add this info also there and will update that ticket in
future for implementing a real fix.
Regards,
Kimmo
|
|
From: T. G. <ti...@ge...> - 2010-08-02 14:01:47
|
Kimmo Varis wrote: > Compiling works for Visual Studio in Windows. Didn't have time to test > in Linux yet. Simple instructions in readme.txt file in repository. I tried to compile the GUI with Qt SDK 4.6.3/Qt Creator 2.0.0 on a Windows Vista and XP machine (both 32 bit) and get the following error (512 times) in the file xrabply.c: invalid suffix "UI64" on integer constant Did you have an idea? Also post as issue to the bitbucket project: http://bitbucket.org/grimmdp/winmerge/issue/1/invalid-suffix-ui64-on-integer-constant Greetings, Tim ___________________________________ NOCC, http://nocc.sourceforge.net |
|
From: Kimmo V. <ki...@wi...> - 2010-08-01 19:41:19
|
Hi all, I've now spent few hours (as I did week ago if somebody noticed) in getting some real coding for WinMerge 3 started. I've now committed some very simple basic things into our repository (http://bitbucket.org/grimmdp/winmerge/). What I've done: - created basic structure for the project directories: * ext - all the external code (like LibXDiff) * lib - non-GUI code (comparing etc) * GUI - Qt GUI code - created qmake project files for compiling LibXDiff - created simple project files for GUI and lib - created simple main window with menubar - created simple Open-dialog which allows selecting two directories - created two classes (FileCompare, DirCompare) which do a simple directory compare. And I mean REALLY simple. It just gets list of files in both directories and compares identical filenames. No left/right-only, no text/binary etc. Just identical/different files. - results are output to debug stream (console in Linux, output view in Visual Studio) I tested this just with one directory and it looked like it worked. But no other testing. So it probably will fail when others test it.. The whole point was not getting a *working* compare, but to have a start for the work. Something people can start working on and improving. Compiling works for Visual Studio in Windows. Didn't have time to test in Linux yet. Simple instructions in readme.txt file in repository. I just repeat again that this is very very initial work to get something started. Feel free to improve things and completely throw out code that doesn't make sense. Regards, Kimmo |
|
From: Kimmo V. <ki...@wi...> - 2010-04-24 13:43:15
|
Hi, as continuation from WinMerge 3.0 moving to Bitbucket and Mercurial Tim asked in forums (https://sourceforge.net/apps/phpbb/winmerge/viewtopic.php?f=9&t=227) if we should separate web pages and code to different repositories. I think this is a good idea in many ways. Web pages are developed independently from other development. I've now converted just two folders from SVN: - Translations/Web - Web as new winmerge-web repository in Bitbucket: http://bitbucket.org/kimmov/winmerge-web I especially didn't convert tags and branches as those are meaningless for the web part. I've also given write access (read: push access) to Dean and Tim. More access per request. If this will be the official repo we use or if Dean or Tim wants to clone this repo under their account is not something I deeply care. It is anyway trivial to move changes between the repositories as long as repositories have relationship (they are clones). But from my point of view this repository (or some of its clone) is ready to be used as our web page repository. Tim also checked the repository that everything needed seems to be in it. Regards, Kimmo |
|
From: Kimmo V. <ki...@wi...> - 2010-04-14 19:37:55
|
Hi, For the record, my WinMergeQt experimentation project that has been mentioned couple of times is available in BitBucket: http://bitbucket.org/kimmov/winmergeqttest/wiki/Home I just realized there were no any instructions how to compile it. I had completely overlooked that critical part. Sorry about that! I've now added instructions for building both QScintilla and WinMergeQr in Windows: http://bitbucket.org/kimmov/winmergeqttest/wiki/Compiling I also improved the project file a bit so that configuring it for Windows should be just fixing two paths. If there are still compiling problems, please let me know. I just checked and compiled it with VS 2008 so instructions should be OK. In Linux you don't need to compile QScintilla yourself but just install it from distro packages (remembering to install the development package too). Yes it is quite many phases in Windows currently. But as this is just experimentation with things I haven't bothered with creating scripts or better project files (yet). -Kimmo > Hi all, > > sorry for the long silence on my part too. To fix both the old look and > cross-platform issues Kimmo mentions below, I have looked last summer or > fall at porting the application to Qt. Kimmo had already listed > somewhere on the wiki issues that needed to be investigated before we > can use that framework (or another) . Unfortunately, I tried to use > Visual Studio to test this and had to stop because something just > wouldn't compile for an obscure reason. Since then I did not have much > spare time to look into the issue. I had the feeling that everything in > Kimmo's list was doable with Qt though and it seemed a really good > framework to work with besides the issues I had (maybe they were related > to QScintilla I can't remember.) |
|
From: Tim G. <ti...@ge...> - 2010-04-09 16:24:26
|
Hi! > * start actively working on GUI improvements. WinMerge is about GUI! If > people don't need/want GUI they use command line diff and patch. Yes, this seams very important! > * get cross-platform effort really going on. We need to support Linux > and Mac. Since I now own a MacBook (as second laptop), this would be good! ;-) > * take a critical look to our features and code and drop useless / niche > features nobody cares/uses. Try to make WinMerge smaller and easier > instead of bigger and more complex. Agreed! > * move out from sourceforge hell. Yes, I just don't want to open sf.net > trackers anymore it is waste of my time every time. They have completely > f*cked up their service making trackers totally useless for me. Want you totally away from SF.net or want only a other tracker? We could use "Trac" as Hosted App. I mean it support now also email notifications. (But we should test it before!) > * start using DVCS instead of SVN. Git and Mercurial allow much more > flexible and easier workflows. We save a lot of time by avoiding manual > applying of patches. Currently the patch review is simply too hard and > takes too much time. Sounds good! Even when I don't understand it full, I use now often Mercurial (TortoiseHg) for my projects at work and home. ;-) > * post "help needed" -messages to sf.net, our mailing lists and forums > telling people how they can start helping us. During the years I've seen > quite a many "I want to help" -messages but only handful of those have > realized to one or more actual patches. I will look, that we get some info also at the website! Greetings, Tim |
|
From: Kimmo V. <ki...@wi...> - 2010-04-08 15:07:39
|
Hi, and thanks for writing this. This is indeed being a problem for a long time already and currently our development is practically stopped. > Currently I see really black for the future from WinMerge! I don't see as 'black'. Just realistic in open source world. One thing I really like in participating OSS projects is you easily see the real status of the project instead of some PR foo. So our situation is that development has practically stopped for several months now. People can see it from SVN logs, from bug tracker etc. If they consider WinMerge is worthwhile project to keep going then for sure somebody steps up and starts helping the project. If there is no enough interest then, well, there are other programs and I hope some of then will grow as stable WinMerge replacement. One reason for the situation is that nowadays everybody wants to create their own compare/merge tool. And so lots of people are working in different projects for the almost same goal. This is the downside of OSS development, unfortunately. It probably would be interesting to see code of those other projects and determine if we could share some code. And fact is our GUI is very old-looking, from W9X era. People want much more fancier GUIs now. If you look at the demos/programs people are already creating with Qt + QML they are simply astonishing. WinMerge simply looks badly outdated. Another reason is "Windows-only". Nowadays lots of people (me included) are developing professionally for Linux. Lots of companies are moving from Windows to Linux. So programs working in both OSes have a big advantage. Some things we can do: * start actively working on GUI improvements. WinMerge is about GUI! If people don't need/want GUI they use command line diff and patch. * get cross-platform effort really going on. We need to support Linux and Mac. * take a critical look to our features and code and drop useless / niche features nobody cares/uses. Try to make WinMerge smaller and easier instead of bigger and more complex. * move out from sourceforge hell. Yes, I just don't want to open sf.net trackers anymore it is waste of my time every time. They have completely f*cked up their service making trackers totally useless for me. * start using DVCS instead of SVN. Git and Mercurial allow much more flexible and easier workflows. We save a lot of time by avoiding manual applying of patches. Currently the patch review is simply too hard and takes too much time. * post "help needed" -messages to sf.net, our mailing lists and forums telling people how they can start helping us. During the years I've seen quite a many "I want to help" -messages but only handful of those have realized to one or more actual patches. Regards, Kimmo |
|
From: Tim G. <ti...@ge...> - 2010-04-07 21:17:44
|
Hi folks! Currently I see really black for the future from WinMerge! Kimmo has less time and interests in WinMerge and I have also less time than in the past. But since I am not a C/C++ developer, I am not that what WinMerge really need. :-( Currently only Takashi maintain his fork <http://www.geocities.co.jp/SiliconValley-SanJose/8165/winmerge.html>, Matthias <http://sourceforge.net/users/matthias1955/> comments on bug reports and I submit languages patches. Maybe we should ask Takashi if he want to move his fork to a SVN branch from WinMerge? So we have the source code near WinMerge and can easier merge good changes. And maybe this advert more and other developer? And maybe we should make Matthias to a official developer? Just some ideas to save this wonderful project! Greetings, Tim |
|
From: Aleix C. F. <al...@me...> - 2009-08-31 08:09:03
|
Hi, I'm the developer of the SCEW library. First of all, I'm very glad to see SCEW is being used in your project, thanks! I'm writing to you because of the upcoming SCEW 1.0 release. This new release includes some API changes (very easy to update from older code) but it's quite more powerful than older releases: - A new I/O system. This allows reading/writing from files/buffers... and allows creating your own readers/writers. - A new scew_list type is used everywhere, for example for element children. Working with lists is much easier and powerful (e.g. scew_list_foreach....). - SCEW types (element, attributes...) comparison and copy. I'm still writing unit tests and need to update documentation and add some tutorial, but the API is quite stable. I'll be very happy if you had some time to have a look and share your comments/critics/suggestions with me. I'm also asking for a bit of help as I haven't update Visual Studio project files, so any help would be really appreciated. Thanks in advance. Best regards, Aleix |
|
From: Kimmo V. <ki...@wi...> - 2009-07-08 23:27:22
|
Hi all, there's been discussions and queries about cross-platform WinMerge for years. We've had some progress in reducing MFC code and lots of our lower level code is already using STL instead of MFC. But the GUI code is MFC and replacing it with some other toolkit is a lot of work. And first we should be choose the toolkit to use. Recently I've been working with QT (and Visual Studio) in another projects so it currently is my preferred framework. It is very nice framework to work with. And in my opinion it is technically superior to WxWidgets which seems to mimic MFC in many things. For example those annoying and ugly message handling macros are there just with another name. But is QT proper to use in WinMerge? Does it offer everything we need? Can we work around issues there possibly are? How we handle translations? Lots of questions. So I started new experimentation project in which I intend to find as many answers I can before doing any actual porting work. If this experimentation project succeeds I hope there is already a good base to start the rest of the porting work. I have started working in public repository at: http://bitbucket.org/kimmov/winmergeqt/wiki/Home There is also wiki where I intend to record my findings as things proceed. There is also discussion thread in WinMerge forums: https://sourceforge.net/apps/phpbb/winmerge/viewtopic.php?f=6&t=127 NOTE: WinMergeQT is NOT WinMerge project fork. Consider it as a testing branch. Current WinMerge project will be the one producing WinMerge releases. I doubt I even do any releases from that testing project. Regards, Kimmo |
|
From: Kimmo V. <ki...@wi...> - 2009-06-25 07:25:54
|
Hi all, we've been doing a lot of work to remove MFC code from our non-GUI code. The target is very clear - WinMerge should be eventually be able to compile with free tools. MFC is not free so we must get rid of it some day. But first step is the division of code to backend/compare code not using MFC and GUI code using MFC (until new non-MFC GUI is developed). Seems that MFC is not easy to remove from plugins code which is pretty integral part of the compare code. So the plugins code is a clear barrier for continuing this MFC-removal work. I haven't seen anybody interested in fixing plugins code and issues for years (some plugins have got fixes but not the system itself). So the plugins system code is clearly not maintained by anybody. Such code gets buggy over the time and that means also it will be dangerous for users data. The only way to proceed is to just remove the plugins code. Which obviously means removing plugins support. I will start disabling and removing plugins code in next weeks. I don't do it in one patch but while I do other MFC code removing and refactoring. But most probably next experimental release is without plugins. I'm not against plugins itself. And perhaps we will have similar system in future properly implemented. Perhaps removing this buggy system will motivate somebody to implementing a good system. Regards, Kimmo |
|
From: Kimmo V. <ki...@wi...> - 2009-05-13 17:47:40
|
Hi all, sf.net announced they will deprecate old forums: http://apps.sourceforge.net/wordpress/sourceforge/2009/05/12/upcoming-feature-deprecation-built-in-forums-docmanager-task-manager/ I've answered their survey and asked data in old forum to be migrated to new forum. We'll see what happens... Regards, Kimmo |
|
From: Tim G. <ti...@ge...> - 2009-03-23 21:01:24
|
Kimmo Varis wrote:
> What kind of translated files we have:
> #1 WinMergeU.exe
> - Src/Languages
> - filename is [languagename].po (German.po)
> #2 Installer
> - Installer/InnoSetup/Languages
> - filename is [languagename].isl (German.isl)
> #3 ShellExtension
> - ShellExtension/Languages
> - filename is ShellExtension[languagename].rc (ShellExtensionGerman.rc)
> #4 Readme
> - Docs/Users/Languages
> - filename is ReadMe-[languagename].txt (ReadMe-German.txt)
> #5 heksedit (as in current trunk)
> - Externals/heksedit/Languages
> - filename is [languagecode].po (ge.po)
>
> Now imagine being translator and:
> - trying to keep up with the changes and keep translations up to date
> - wanting to translate WinMerge and find all those files
>
> Many translators find/bother only with WinMergeU.exe part.
>
> First problem of files being scattered all over folder structure could
> be solved by creating new top-level folder for them. E.g.
> "Translations". Under that folder we could have own subfolder for each
> component having actual files. Like this:
>
> Translations
> |-Installer
> | |-German.isl
> | |-Spanish.isl
> [...]
> |-Readme
> | |-ReadMe-German.txt
> | |-ReadMe-Spanish.txt
> [...]
>
> The problem with different filenaming schemes is trickier. Jochen's idea
> to use languagecode is good. But only language code makes filenames
> short and "uncomfortable". Where is the German file? And we have two
> Chinese translations.
>
> Currently we also have a bit weird naming for executable lang files.
> E.g. we have Brazilian.po and Portuguese.po. Which isn't very logical.
>
> [...]
I am working on a translation system for our website. It is now only
alpha code, but sooner or later we will have new translations files. So
I think we should discus this schema again.
We both like "languagecode_countrycode.po" most, right?
So I would get the following structure for the new translations:
Translations
|- Web
|- de_DE.po
|- fr_FR.po
|- ...
Greetings,
Tim
|
|
From: Tim G. <ti...@ge...> - 2009-03-06 21:17:10
|
Kimmo Varis wrote: > I've just uploaded WinMerge 2.12.0 stable release to sf.net. And I just updated the website and added a news entry to the SF.net project page. Lets the downloads begin! :) Greetings, Tim |
