|
|
|
|
||||||
| alt.internet.seo Internet search engines and related topics. |
![]() |
|
|
LinkBack | Outils de la discussion |
|
|
#176 |
|
Messages: n/a
Hébergeur: |
Big Bill <kruse@cityscape.co.uk> wrote:
> On 2 Sep 2006 05:01:06 GMT, John Bokma <john@castleamber.com> wrote: [..] >>invalid code doesn't require more storage space or less :-) > > Bloated code does though and there's rather more chance of code > suffering from bloat if it doesn't validate than not. That's the > point. I am not sure about the latter, nor about the former. Most compression algorithms work by assigning as little bits as possible to the most repeated structures meaning that bloated code can compress as well or maybe better then lean code. >>Easier/cheaper for people developing parsers maybe. But in general? I >>can't think of any reason why. > > Easier to spider? Less time taken to grasp the meaning of a page's > content? A parser can just drop all bloat very easily. It takes more time, but we're talking about very very little time. > More accurate indexing - no more "miserable failures"? My best guess is, and that's how it's probably implemented, is that a parser just does several reductions (it's close to constant folding, or maybe one can say equal to). It's not that hard to rewrite: <font face="glalallddl" size=6><b><i>bla bla</b></i></font> into <h1>bla bla</h1> (even with the b and i closing tags interchanged). -- John Need with SEO? Get started with a SEO report of your site: --> http://johnbokma.com/websitedesign/seo-expert-.html |
|
|
|
#177 |
|
Messages: n/a
Hébergeur: |
Borek <m.borkowski@delete.chembuddy.these.com.parts> wrote:
> On Sat, 02 Sep 2006 07:01:06 +0200, John Bokma <john@castleamber.com> > wrote: > >>> It matters for a search engine with finite storage though. Think how >>> much money they'd save on servers if everyone validated routinely. >> >> invalid code doesn't require more storage space or less :-) > > In terms of storage space we agree. > >>>> People who validate look at their code in a different way IMO, and >>>> learn to code cleaner, resulting in easier to maintain sites. >>> >>> Easier/cheaper for the engines too. >> >> Easier/cheaper for people developing parsers maybe. But in general? I >> can't think of any reason why. > > But here I have some doubts. I can be wrong, but intuition tells me > that you need more processing power to analyze broken code, than to > analyze correct one. So I would expect savings in terms of processing > power. Judging from the G operations scale even 1% saving can be huge > in terms of money. It's still hard to say. Parsing is just deciding for each element what to do. With bloated code the action can be very often "throw away", which is cheap. At other times the parsed code must be fixed, which can be expensive. But I think that the main issue here is that bloated and invalid are not identical. I have seen valid XHTML on sites which is extremely bloated because the site looks good (look at code to make a rectangle with nice rounded corners and you get my point). -- John Need with SEO? Get started with a SEO report of your site: --> http://johnbokma.com/websitedesign/seo-expert-.html |
|
|
|
#178 |
|
Messages: n/a
Hébergeur: |
On 2 Sep 2006 18:46:48 GMT, John Bokma <john@castleamber.com> wrote:
>Big Bill <kruse@cityscape.co.uk> wrote: > >> On 2 Sep 2006 05:01:06 GMT, John Bokma <john@castleamber.com> wrote: > >[..] > >>>invalid code doesn't require more storage space or less :-) >> >> Bloated code does though and there's rather more chance of code >> suffering from bloat if it doesn't validate than not. That's the >> point. > >I am not sure about the latter, nor about the former. Most compression >algorithms work by assigning as little bits as possible to the most >repeated structures meaning that bloated code can compress as well or >maybe better then lean code. Yeah, byte for byte, but if there's a whole load of unnecessary bytes to begin with then there'll be more code at the end than there need be, whether it be compressed or not. If someone codes with an eye for economy, then the code they use to generate a page will be smaller than the code generated by something like DW or, God us, FP. So it's going to be easier to handle every which way. >>>Easier/cheaper for people developing parsers maybe. But in general? I >>>can't think of any reason why. >> >> Easier to spider? Less time taken to grasp the meaning of a page's >> content? > >A parser can just drop all bloat very easily. It takes more time, but >we're talking about very very little time. > >> More accurate indexing - no more "miserable failures"? > >My best guess is, and that's how it's probably implemented, is that a >parser just does several reductions (it's close to constant folding, or >maybe one can say equal to). It's not that hard to rewrite: > ><font face="glalallddl" size=6><b><i>bla bla</b></i></font> > >into > ><h1>bla bla</h1> (even with the b and i closing tags interchanged). but rewriting it isn't quite the same as grasping the implied meaning, something which Google has arguably always been weak at, as evidenced by their reliance on human opinion in the form of DMOZ and more lately anchor text. BB -- http://www.crystal-liaison.com/crystal-world/index.html http://www.crystal-liaison.com/cryst...-elephant.html http://www.crystal-liaison.com/cryst...can-eagle.html |
|
|
|
#179 |
|
Messages: n/a
Hébergeur: |
Big Bill <kruse@cityscape.co.uk> wrote:
> On 2 Sep 2006 18:46:48 GMT, John Bokma <john@castleamber.com> wrote: > >>Big Bill <kruse@cityscape.co.uk> wrote: >> >>> On 2 Sep 2006 05:01:06 GMT, John Bokma <john@castleamber.com> wrote: >> >>[..] >> >>>>invalid code doesn't require more storage space or less :-) >>> >>> Bloated code does though and there's rather more chance of code >>> suffering from bloat if it doesn't validate than not. That's the >>> point. >> >>I am not sure about the latter, nor about the former. Most compression >>algorithms work by assigning as little bits as possible to the most >>repeated structures meaning that bloated code can compress as well or >>maybe better then lean code. > > Yeah, byte for byte, but if there's a whole load of unnecessary bytes > to begin with then there'll be more code at the end than there need > be, whether it be compressed or not. aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaa.... can be compressed to nxa (n times a) while abcdefgh can't be compressed. So bloated code can, due to its repetitive character, maybe better compressed compared to non-bloated. Mind, I agree with you that we all should write non-bloated correct code etc. But one can't say by looking at 2 pieces of code which compresses better. > If someone codes with an eye for > economy, then the code they use to generate a page will be smaller > than the code generated by something like DW or, God us, FP. No, like I said, with compression (which web servers can do if the client supports it), it might be that the bloated one is smaller and takes up less bytes because it compresses better due to the huge amount of repetition. > So > it's going to be easier to handle every which way. For people who can't handle hand coded HTML DW is easier to handle. They don't care about how it looks on the inside. Compare it to: I like to have the cables inside my PC out of the way of the main air flow, nicely put together. Also, I clean the inside of my PC several times a year. Most people see only the outside of their computer, and don't care about how it looks on the inside. Not even if you tell them that their computer can break because of overheating. It hasn't happened to them, so *shrugh*. Some have looked inside a computer once, and got scared. Others have even tried something in the past (hardware upgrade, or even cleaning), and broke something. Some time ago I didn't push the graphics card back, and got weird start up problems. I know my hardware, and was able to fix it. Others probably had to walk to a PC shop and pay 100-150USD (and got sold a new graphics card, or a new motherboard and power supply, or an entire new computer because their computer was beyond repair). So even if cleaning a computer is a piece of cake, most don't care to learn it. For the same reason most people are happy enough with DW, FP, or blog templates, or whatever, and don't care about dust on their HTML cables. >><font face="glalallddl" size=6><b><i>bla bla</b></i></font> >> >>into >> >><h1>bla bla</h1> (even with the b and i closing tags interchanged). > > but rewriting it isn't quite the same as grasping the implied meaning, The rewriting is based on the guess that a font size of 6 might be comparable with a h1, which might be right or wrong :-). The reason why people should use semantical HTML is clear :-). > something which Google has arguably always been weak at, as evidenced > by their reliance on human opinion in the form of DMOZ and more lately > anchor text. Yes, and in the future this will probably change more and more. Partly because bots get smarter, and probably because more people start one or more blogs, and they all want to be #1. Of course they all search more, but I am afraid that the number of pages grows faster. Sometimes I see a site on #1 and wonder, does that site deserve to be on one? For example: http://www.google.com/search?q=firefox%20rss I am #1 here. Do I deserve to be above mozilla and Sage? (Yes, I really do ask myself that question now and then). -- John Need with SEO? Get started with a SEO report of your site: --> http://johnbokma.com/websitedesign/seo-expert-.html |
|
|
|
#180 |
|
Messages: n/a
Hébergeur: |
On 2 Sep 2006 04:19:40 GMT, John Bokma <john@castleamber.com> wrote:
>David <seodave@search-engine-optimization-services.co.uk> wrote: > >> Because the majority of sites do not validate and so don't follow all >> W3C recommendations. If Google insisted on validation it would have a >> very small index! > >Unless they start to push sites down that don't validate, and clearly >state why this is happening. Before you know it a lot of sites suddenly >validate, word! Yes Google could make validation a factor and I think it would be a good thing (better accessibility), but I see no evidence it's happening now. >> I agree it SHOULD be considered as a factor, but currently there is no >> evidence Google gives sites that validate a ranking boost. I'd be very >> happy if it did since most of my stuff validates. > >Maybe it happens, but it's such a minor factor that in your case the other >good factors make it unsignificant. Moreover, it might be very well the >case that this factor is increased every week. If it is then it's a VERY small factor. I'm not saying it's not a factor I'm saying I see no evidence it's a factor. That said if I had to say either way I'd go with believing Google doesn't use validation per se in it's ranking algo. >OTOH: for most visitors it doesn't matter a single bit if a page validates >or not. One can make valid pages that work only in one page, and invalid >pages that work in all browsers. And that's why I think validation isn't considered by Google. >I *do* recommend validation because people who do so learn often what >semantic mark up means (good for SEO), and don't risk misinterpretation of >their mark up by automatic processes that analyze this semantic stuff. I validate new template pages (mostly, occasionally forget), but I don't have a problem using code that doesn't validate. >People who validate look at their code in a different way IMO, and learn >to code cleaner, resulting in easier to maintain sites. Maybe, I hand code so don't need to validate in general. Webmasters using WYSIWYG editors really should validate after every template change because they are prone to messing up code! Though I suppose if they have to use a WYSIWYG editor they might have problems hand coding so validation is beyond them! >> Probably will eventually, but not until a significant number of sites >> validate. As it is the norm is NOT to validate, so there is no gain >> for Google to give a site a boost for validating. > >If XHTML is going to break through and used as true XML, and not funky >HTML people soon enough will learn to validate :-) Yep, but we'll still see basic HTML pages that work great in IE, but not so great in FireFox etc... for a decade or two :-) That is unless Microsoft actually create a browser that works according to current recommendations then a lot of sites will have to update their code (though there will still be a lot of old sites that never update). Really arrogant and irresponsible of MS to have created IE the way they did! Imagine the man hours webmasters have wasted trying to get their sites working in all major browsers because they designed primarily for IE. David -- SEO Tutorial http://www.seo-gold.com/tutorial/ More Earnings Blog http://www.morearnings.com/ |
|
|
|
#181 |
|
Messages: n/a
Hébergeur: |
On Sat, 02 Sep 2006 05:59:22 GMT, Big Bill <kruse@cityscape.co.uk>
wrote: >>>>OTOH: for most visitors it doesn't matter a single bit if a page >>>>validates or not. One can make valid pages that work only in one page, >>>>and invalid pages that work in all browsers. >>> >>> It matters for a search engine with finite storage though. Think how >>> much money they'd save on servers if everyone validated routinely. >> >>invalid code doesn't require more storage space or less :-) > >Bloated code does though and there's rather more chance of code >suffering from bloat if it doesn't validate than not. That's the >point. Bloated code can validate, so that's a different thing altogether. Are you suggesting Google will give a page a boost for using less markup code now? I can tell you as someone who tends to use less markup code than most it's highly unlikely to be true. >>>>I *do* recommend validation because people who do so learn often what >>>>semantic mark up means (good for SEO), and don't risk >>>>misinterpretation of their mark up by automatic processes that analyze >>>>this semantic stuff. >>>> >>>>People who validate look at their code in a different way IMO, and >>>>learn to code cleaner, resulting in easier to maintain sites. >>> >>> Easier/cheaper for the engines too. >> >>Easier/cheaper for people developing parsers maybe. But in general? I >>can't think of any reason why. > >Easier to spider? Less time taken to grasp the meaning of a page's >content? Google's bot will have a set of routines that analyse every page the same way, so I don't think there'll be a discernable difference between a valid and a non-valid page especially when you consider the difference between validation and non validation can be minor differences. John probably has a better grasp of resources used by a parser if the code is broken relative to not broken? >More accurate indexing - no more "miserable failures"? Why would validation remove/prevent Googlebombs bill? Also on your bloat thing, I had a template that I didn't validate after adding AdSense ads to it. Turns out I'd missed some code (set of li tags) so making it valid added more code not less. Another example is with floating divs (which I use a lot), after using a right and left float you should use clear otherwise it messes with some browsers. IE however doesn't need clear, so making the code validate again meant adding more code, not less. So you can't assume validating means less code used! David -- Totally Duh! http://www.totallyduh.com/ SEO Services http://www.seo-gold.com/expert-seo-consultant.php |
|
|
|
#182 |
|
Messages: n/a
Hébergeur: |
David <seodave@search-engine-optimization-services.co.uk> wrote:
> Yep, but we'll still see basic HTML pages that work great in IE, but > not so great in FireFox etc... for a decade or two :-) That is unless > Microsoft actually create a browser that works according to current > recommendations then a lot of sites will have to update their code > (though there will still be a lot of old sites that never update). I recall having read that that's the current problem they are facing: how to fix IE in such a way that 99% of the Matrix is not overtaken by Mr. Smith :-D. > Really arrogant and irresponsible of MS to have created IE the way > they did! OTOH, one of their major problems is that they wrote a render engine, and had to tweak it and tweak it, and then in order to keep up it would take too many man hours, so I guess someone decided that IE should limp along as long as possible. There was a good reason why Netscape switched to Gecko. > Imagine the man hours webmasters have wasted trying to get > their sites working in all major browsers because they designed > primarily for IE. Uhm... I am afraid most webmasters didn't waste time because they designed primarily for IE :-D. They probably do have to invest some time to fix those sites when IE7 final comes out (or lets hope). On the other hand, the Web2.0 bubble will be close to its max by then, so most will probably already being busy updating their sites :-D. -- John Need with SEO? Get started with a SEO report of your site: --> http://johnbokma.com/websitedesign/seo-expert-.html |
|
|
|
#183 |
|
Messages: n/a
Hébergeur: |
David <seodave@search-engine-optimization-services.co.uk> wrote:
> differences. John probably has a better grasp of resources used by a > parser if the code is broken relative to not broken? Only if Google give me the code :-) I have no idea. I can write parsers, but have never written one for HTML. I do understand the big picture, but even if I wrote my own HTML parser, it doesn't mean that Google's parser works the same. Earlier I gave an example that <font....><b><i>... etc. could be internally rewritten to h1 (based on the size=6), but that was just an example. But I can imagine that Google does do things like that. [snip] > is with floating divs (which I use a lot), after using a right and > left float you should use clear otherwise it messes with some > browsers. IE however doesn't need clear, so making the code validate > again meant adding more code, not less. So you can't assume validating > means less code used! Depends a lot on the situation (I know what you mean, you get that stuff "leaks up"), but sometimes you can set the clear: both (IIRC) on the next element, without having to add extra HTML. But I hand the mic to Els for this one :-D. -- John Need with SEO? Get started with a SEO report of your site: --> http://johnbokma.com/websitedesign/seo-expert-.html |
|
|
|
#184 |
|
Messages: n/a
Hébergeur: |
John Bokma wrote:
> [...] and don't care about dust on their HTML cables. And I thought I understood both HTML and the insides of my pc! :S -- Els http://locusmeus.com/ accessible web design: http://locusoptimus.com/ |
|
|
|
#185 |
|
Messages: n/a
Hébergeur: |
On 2 Sep 2006 23:08:28 GMT, John Bokma <john@castleamber.com> wrote:
>Big Bill <kruse@cityscape.co.uk> wrote: > >> On 2 Sep 2006 18:46:48 GMT, John Bokma <john@castleamber.com> wrote: >> >>>Big Bill <kruse@cityscape.co.uk> wrote: >>> >>>> On 2 Sep 2006 05:01:06 GMT, John Bokma <john@castleamber.com> wrote: >>> >>>[..] >>> >>>>>invalid code doesn't require more storage space or less :-) >>>> >>>> Bloated code does though and there's rather more chance of code >>>> suffering from bloat if it doesn't validate than not. That's the >>>> point. >>> >>>I am not sure about the latter, nor about the former. Most compression >>>algorithms work by assigning as little bits as possible to the most >>>repeated structures meaning that bloated code can compress as well or >>>maybe better then lean code. >> >> Yeah, byte for byte, but if there's a whole load of unnecessary bytes >> to begin with then there'll be more code at the end than there need >> be, whether it be compressed or not. > > >aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaa.... > >can be compressed to nxa (n times a) > >while > >abcdefgh > >can't be compressed. > >So bloated code can, due to its repetitive character, maybe better >compressed compared to non-bloated. > >Mind, I agree with you that we all should write non-bloated correct code >etc. But one can't say by looking at 2 pieces of code which compresses >better. > >> If someone codes with an eye for >> economy, then the code they use to generate a page will be smaller >> than the code generated by something like DW or, God us, FP. > >No, like I said, with compression (which web servers can do if the >client supports it), it might be that the bloated one is smaller and >takes up less bytes because it compresses better due to the huge amount >of repetition. > >> So >> it's going to be easier to handle every which way. > >For people who can't handle hand coded HTML DW is easier to handle. They >don't care about how it looks on the inside. > >Compare it to: I like to have the cables inside my PC out of the way of >the main air flow, nicely put together. Also, I clean the inside of my >PC several times a year. Most people see only the outside of their >computer, and don't care about how it looks on the inside. Not even if >you tell them that their computer can break because of overheating. It >hasn't happened to them, so *shrugh*. > >Some have looked inside a computer once, and got scared. Others have >even tried something in the past (hardware upgrade, or even cleaning), >and broke something. > >Some time ago I didn't push the graphics card back, and got weird start >up problems. I know my hardware, and was able to fix it. Others probably >had to walk to a PC shop and pay 100-150USD (and got sold a new graphics >card, or a new motherboard and power supply, or an entire new computer >because their computer was beyond repair). > >So even if cleaning a computer is a piece of cake, most don't care to >learn it. For the same reason most people are happy enough with DW, FP, >or blog templates, or whatever, and don't care about dust on their HTML >cables. > >>><font face="glalallddl" size=6><b><i>bla bla</b></i></font> >>> >>>into >>> >>><h1>bla bla</h1> (even with the b and i closing tags interchanged). >> >> but rewriting it isn't quite the same as grasping the implied meaning, > >The rewriting is based on the guess that a font size of 6 might be >comparable with a h1, which might be right or wrong :-). The reason why >people should use semantical HTML is clear :-). > >> something which Google has arguably always been weak at, as evidenced >> by their reliance on human opinion in the form of DMOZ and more lately >> anchor text. > >Yes, and in the future this will probably change more and more. Partly >because bots get smarter, and probably because more people start one or >more blogs, and they all want to be #1. Of course they all search more, >but I am afraid that the number of pages grows faster. > >Sometimes I see a site on #1 and wonder, does that site deserve to be on >one? For example: > >http://www.google.com/search?q=firefox%20rss > >I am #1 here. Do I deserve to be above mozilla and Sage? (Yes, I really >do ask myself that question now and then). Els! He's starting again! BB -- http://www.crystal-liaison.com/crystal-world/index.html http://www.crystal-liaison.com/cryst...-elephant.html http://www.crystal-liaison.com/cryst...can-eagle.html |
|
|
|
#186 |
|
Messages: n/a
Hébergeur: |
On 3 Sep 2006 01:33:46 GMT, John Bokma <john@castleamber.com> wrote:
>David <seodave@search-engine-optimization-services.co.uk> wrote: > >> Yep, but we'll still see basic HTML pages that work great in IE, but >> not so great in FireFox etc... for a decade or two :-) That is unless >> Microsoft actually create a browser that works according to current >> recommendations then a lot of sites will have to update their code >> (though there will still be a lot of old sites that never update). > >I recall having read that that's the current problem they are facing: how >to fix IE in such a way that 99% of the Matrix is not overtaken by Mr. >Smith :-D. > >> Really arrogant and irresponsible of MS to have created IE the way >> they did! > >OTOH, one of their major problems is that they wrote a render engine, and >had to tweak it and tweak it, and then in order to keep up it would take >too many man hours, so I guess someone decided that IE should limp along >as long as possible. There was a good reason why Netscape switched to >Gecko. > >> Imagine the man hours webmasters have wasted trying to get >> their sites working in all major browsers because they designed >> primarily for IE. > >Uhm... I am afraid most webmasters didn't waste time because they designed >primarily for IE :-D. They probably do have to invest some time to fix >those sites when IE7 final comes out (or lets hope). Springtime for coders! BB -- http://www.crystal-liaison.com/crystal-world/index.html http://www.crystal-liaison.com/cryst...-elephant.html http://www.crystal-liaison.com/cryst...can-eagle.html |
|
|
|
#187 |
|
Messages: n/a
Hébergeur: |
Big Bill <kruse@cityscape.co.uk> wrote:
> On 2 Sep 2006 23:08:28 GMT, John Bokma <john@castleamber.com> wrote: [..] >>http://www.google.com/search?q=firefox%20rss >> >>I am #1 here. Do I deserve to be above mozilla and Sage? (Yes, I really >>do ask myself that question now and then). > > Els! He's starting again! Also #3 for perl programmer :-p -- John Need with SEO? Get started with a SEO report of your site: --> http://johnbokma.com/websitedesign/seo-expert-.html |
|
|
|
#188 |
|
Messages: n/a
Hébergeur: |
On 3 Sep 2006 02:52:37 GMT, John Bokma <john@castleamber.com> wrote:
>[snip] > >> is with floating divs (which I use a lot), after using a right and >> left float you should use clear otherwise it messes with some >> browsers. IE however doesn't need clear, so making the code validate >> again meant adding more code, not less. So you can't assume validating >> means less code used! > >Depends a lot on the situation (I know what you mean, you get that stuff >"leaks up"), but sometimes you can set the clear: both (IIRC) on the next >element, without having to add extra HTML. But I hand the mic to Els for >this one :-D. You can add the clear to the next element, but it still means adding more code. I've been lazy with this code http://www.classic-literature.co.uk/...wse-10248.html Wrote it up inline and didn't get around to pushing the CSS externally. Each product uses multiple floating divs. You have the product image, description and price, 3 left floating divs. For each set of three there's a div style="clear: left;" so 10 of those since ten products. If I give it a class say clearL you still need to add class="clearL" to something so it's adding extra code. It's not a lot, but point was not to assume that validating means less code sometimes the work around for a problem adds more code. David -- What’s This Pic Game http://www.totallyduh.com/tag/whats-this-pic/ http://www.morearnings.com/2006/07/1...ltant-ranking/ |
|
|
|
#189 |
|
Messages: n/a
Hébergeur: |
On Mon, 28 Aug 2006 18:22:59 +0200, "Jezsta Web Productions"
<Please-use-our-contact-form@jezsta.com> wrote: >Now I see it. I seen Els before yours. Your news server must be running >slow. i'd say. Your just appeared now. 05-sept !! plh Paul -- Handmade Jewelry http://www.houstoncrafts.com/beaded/earrings-107.html http://www.houstoncrafts.com/Swarovs...rings-310.html http://www.houstoncrafts.com/pearl/necklace-105.html ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- |
|
|
|
#190 |
|
Messages: n/a
Hébergeur: |
"Royceee" <royce.bathrooms@btconnect.com> wrote in message news:M7ednYix5PSjqm3ZnZ2dnUVZ8smdnZ2d@bt.com... > Hello > > Although my site is doing pretty well on Google, Im searching for ways to > make it do better, I have got some links coming into my site which has > made my PR good but im looking for ways to further improve my search > engine results. > I read that untidy code and more code than content can slow things down. > Is this true? > Also am I taking the P with the use of my keywords (too many)? > Is it also true that a 'Breadcrumb' s as it is textual links around > the site? > Any and/or tips would be very very much appreciated you lovley people > :P > PS can anyone sell me PR? > www.roycebathrooms.co.uk > > > Thank you all so much for your guys, an amazing response I am totally shocked and so many suggestions, I am very gratefull |
|
![]() |
| Outils de la discussion | |
|
|