All image directories and img links can be discovered and converted in an offline checkout of the site.
It could be automated. Different image files of the same name can be diffed. It is all discoverable. Doing it manually is a mess. I discovered this during the ooo-site port from Oracle's Kenai which was actually a recent port from CollabraNet that was rather broken. The point is that OOo is a mess different project sites did different things. There are some beautiful yurts on the Mongolian site: http://www.openoffice.org/mn/ Regards, Dave On Apr 4, 2013, at 3:32 PM, Marcus (OOo) wrote: > Am 04/05/2013 12:18 AM, schrieb Rob Weir: >> On Thu, Apr 4, 2013 at 5:27 PM, Kay Schenk<kay.sch...@gmail.com> wrote: >> >>> On Mon, Apr 1, 2013 at 3:52 PM, Marcus (OOo)<marcus.m...@wtnet.de> wrote: >>> >>>> Am 04/01/2013 03:12 AM, schrieb Rob Weir: >>>> >>>> On Sun, Mar 31, 2013 at 11:12 AM, Marcus (OOo)<marcus.m...@wtnet.de> >>>>> wrote: >>>>> >>>>>> Hi Rob, >>>>>> >>>>>> I want to cleanup the structure and remove 1 of the 2 directories for >>>>>> images. >>>>>> >>>>>> Therefore I've added the images from "download/images" also to >>> "images/" >>>>>> and >>>>>> updated the "download/index.html" to point to the new location. >>>>>> >>>>>> Please tell me, is it save to remove the "download/images/" directory? >>> If >>>>>> not what else has to be updated? >>>>>> >>>>>> >>>>> I'm not sure I like the idea of having a global images directory >>>>> rather than having images scoped to the subtree where they are >>>>> actually used. Having a single global directory increases the changes >>>>> of having accidental conflicts. But if you want to make this change, >>>>> >>>> >>>> That's not what I want. Please read again. I just want to get rid of 1 of >>>> the 2 images directories in the "download/" sub-dir. >>>> >>>> Of course it doesn't make sense to have a single images dir for the >>> entire >>>> website. ;-) >>> >>> >>> Actually I don't think a single "images" directory for the whole site is >>> such a bad idea. We could subdivide it by area -- e.e. images/download. >>> Maybe worth discussing at some point? >>> >>> >> What advantage do you see to that? I could see that for common images that >> were essentially "global" this might make sense. But otherwise having >> images contained in the subtree that uses them gives more isolation, >> prevents name collisions, accidental side effects, etc. >> >> Of course from an information standpoint foo/bar and bar/foo are equally >> expressive. But I think we're more likely to copy, move, translate, etc., >> subsites as a whole, so having, e.g., /download be self-contained is a nice >> property. >> >> >>> >>>> >>>> be sure to test each of the "Help spread the word" links for >>>>> Twitter/Facebook/Google+ to make sure those applications are finding >>>>> the right images. I don't mean the image on our page. I mean the >>>>> image on the post once it is on Facebook, etc. Since hundreds of such >>>>> posts have already been made, we probably don't want to break any of >>>>> those links. >>>>> >>>> >>>> You mean Twitter/Facebook/Google+ articles are referring to >>>> ".../download/images/*" files? That's bad, then we won't never be able to >>>> move such kind of files in the future. >>>> >>> >> >> I don't know this. I'm just suggesting that it is something we should >> check. We have over 7 million external links into www.openoffice.org. So >> it is hard to make any significant changes without breaking something. But >> that shouldn't prevent us from making improvements. But if we make any big >> changes we'll want to go back and see if any critical external sites need >> to be notified/updated. > > When I see this correct, then the files that you have checked-in into > "www.oo.org/download/images/" are not that old - much more recent than the > files in "www.oo.org/download/cachedimages/". IMHO not enough to get > wide-spreaded like other data on our website. > > Do you remember where you have used the image files? Then I (or you) could > change the links to the new files in "www.oo.org/images/". And any more > broken links can be changed then. > > So, can you help me with this? > > Thanks > > Marcus > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
