Hi Johannes 2011/4/7 Johannes Schmid <j...@jsschmid.de>: > Hi! > >> At this point this it is just an idea and I am very much looking for >> feedback. >> Would this be helpful? >> Will developers play along? >> Will this be acceptable within the design goals of Damned Lies (Claude)? >> Should the information in this columns be what I wrote, or is there >> something else that would be more helpful? > > As there are still "rules to be defined" for the applications included, > this is difficult to tell. However, I think at least a list of release > dates would be helpful as long as it can be generated automatically from > GNOME releases and only those modules that have other dates would need > to update them accordingly (which could send a mail to gnome-i18n).
Yes, that is the idea. The assumption is that all modules on one page in damned lies has to adhere to the same set of rules (whatever they may be). So either they are required to follow GNOME release schedule or they are not. If they are not _required_ then they inform DL (in one way or another) whether they still intend on following the GNOME release schedule (in which case the information can be autogenerated), and if they don't, they provide a date, when they have one. It was never the idea that all modules in DL had to have this information, if there is no release planned, then they don't set the date and we will know that it is lower priority. Then when they decide to plan a release, they set the date and we start translating. About the list, I think it is crucial that it is in DL since, as a translator, that is the center of my whole world ;). The information needs to be right there next to the number of strings needing to be updated. Concerning how to change the release date for your module, I think it is important that it is something that developers and documenters can do without any "middle men". I'm a low tech kind of guy, so I would just ask them to put this information in a file somewhere in the source tree and have DL parse it, maybe there is a better way, but it has to be easy and direct. > The documentation part seems difficult to me because it is always hard > to tell how up-to-date documentation is. But it would be nice to have a > marker that says "Don't translated, this is outdated/being updated". The documenters know how up to date their documentation is. So the only things that is required is, that when they bring the documentation up to par with a certain release of to the state of current trunk, then they write down that release of the date in a file, that DL then parses. Same thing for marking it as DO NOT TRANSLATE, when you start rewriting the documentation from scratch, write it in that magical file and the information will be on DL. Regards Kenneth _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n