Jeśli Twój serwis jest wielojęzykowy, to pewnie użyłeś jednego ze sposóbów na przekazywanie wersji językowej w adresie URL:

1. Zmienna językowa w query string, np.: http://mojadomena.pl/podstrona?lang=pl
2. Zmienna językowa jako podkatalog, np: http://mojadomena.pl/en/podstrona/
3. Zmienna językowa jako subdomena, np: http://en.mojadomena.pl
4. Zmienna językowa przypisana do domeny (odrębna dla każdej domeny), np: http://mojadomena.pl, http://mojadomena.co.uk

O ile w pierwszym i drugim przypadku budowa mapy jest oczywista, bowiem mapa zawiera wszystkie URL niezależnie od języka, tak w przypadku subdomeny lub domeny wyłącznie dla jednego języka, mapa będzie zawierać URL tylko z tej wersji językowej. A skoro serwis fizycznie zajmuje to samo miejsce na serwerze, tak więc i mapa serwisu dla każdej wersji jezykowej będzie w tym samym miejscu.
Ale przecież zgodnie z sugestią Google plik mapy ma mieć ustaloną nazwę, np. sitemap.xml (dla mapy w formcie XML) lub sitemap.txt (dla mapy w postaci pliku tekstowego). Na pewno nie mogą to być pliki o nazwach sitemap_pl.xml dla wersji polskiej i sitemap_en.xml dla wersji angielskiej.

Ooo, już nie będzie tak kolorowo jak przy poprzednich wpisach. Zapoznamy się z problemem wyszukiwania podobnego (najbliższego) koloru dla zadanego koloru, przy założeniu, że działamy w ograniczonej palecie (np. mamy do czynienia z paletą indeksowaną).

Być może nie miałeś w ogóle styczności z tym problemem i czytasz wpis tylko z czystej ciekawości (co mnie również bardzo cieszy), więc wyjaśnię Ci na początek czym jest paleta indeksowana.

Z tym rodzajem palety mamy do czynienia, kiedy przechowujemy tabelę zawierającą pod kolejnymi indeksami kolory użyte w pliku graficznym.
Nie ma więc tu sytuacji, że każdy element grafiki (załóżmy piksel) jest określony przez indywidualny kolor. Zakładając, że mamy do czynienia z trybem RGB (bez kanału alpha) i pikselem białym w prawym górnym rogu, jest on określony poprzez grupę bajtów 255, 255, 255, a kolor czarny na prawno od niego, określony jest jako 0,0,0. Jeśli trzeci piksel jest znów biały, to jego miejsce w pliku zajmuje grupa 255, 255, 255.
W przypadku grafiki opartej na palecie indeksowanej, kolor biały może być przechowywany pod indeksem 0 w tabeli palety, a kolor czarny pod indeksem 1 tejże tabeli. Kolejność przechowywania kolorów w tabeli palety nie ma żadnego znaczenia, tzn. kolory nie muszą być ustawione w kolejności jasności czy relatywnie do położenia na kole barw. Tu trzy piksele (biały, czarny, biały) grafiki, będą reprezentowane w pliku poprzez wartości 0, 1, 0, odpowiadając indeksom w tabeli palety, czyli de facto kolorom, ale nie w sposób bezpośredni.

Rezprezentacja w pamięci obrazu (3 piksele) opartego o paletę bezpośrednią:

Kluczysz, miotasz się jak szatan, uciekasz przez wszystkie podstrony serwisu, wracasz, a adres URL z którym biegniesz, nadal ciągnie za sobą ogon. Ogon w postaci query string.

Jak się go pozbyć przy przepisywaniu lub przekierowywaniu adresów URL?

Są dwa sposoby:

1. Dodajemy znak zapytania na końcu wyrażenia regularnego reguły przepisywania/przekierowania.
2. Dodajemy flagę [QSD] (query string discard). Flaga jest dostępna w Apache od wersji 2.4.

Bycie swatką lub swatem w życiu na pierwszy rzut oka wydaje się prostym i wdzięcznym zajęciem. Jeśli para ma się ku sobie, sprawa załatwiona, gorzej jeśli dwa "elementy" nijak nie chcą się zejść.

Ostatnio przykleiło się do mnie podobne zadanie, ale na szczęście nie w życiu, choć i tu perturbacje były spore. Miałem potrzebę połączenia dwóch tablic, z których jedna z nich zawierała elementy na pozycjach nieparzystych, a druga na pozycjach parzystych. Problem wydaje się prosty, ale celem było otrzymanie tablicy, w której kolejno na pozycje nieprzyste wpadają elementy z tablicy "nieparzystej", a na pozycje parzyste elementy z tablicy "parzystej". No i nadal problem nie wydaje się skomplikowany...
Jednak jest jeszcze jedna kluczowa (sic!) kwestia, mianowcie obydwie tablice były asocjacyjne, a klucze i kolejność występowania elementów w każdej z nich musiała być odwzorowana w tabeli docelowej.

Podsumowując, założenia są następujące:

• mamy dwie tablice źródłowe,
• obydwie tablice są asocjacyjne,
• obydwie tablice są tej samej długości,
• na pozycjach, które nas nie interesują mogą wystąpić dowolne wartości,
• klucze mają być zachowane,
• kolejność ma być zachowana.

Przykładowe tablice źródłowe:

$array1 = [23 => 'a', 14 => null, 1 => 'b', 56 => ''];
$array2 = [2 => 'xxx', 6 => 'c', 11 => null, 'o1' => 'd'];

A docelowa ma wyglądać tak:

$array = [23 => 'a', 6 => 'c', 1 => 'b', 'o1' => 'd'];

Zdarzyło Ci się kiedyś używac metody split w JavaScript? Jeśli używałeś, to pewnie po to, aby rozdzielić tekst "sklejony" przecinkami czy średnikami.

A co jeśli tekst byłby połączony różnymi znakami... Rozcinać je kilkukrotnie? Ciach, ciach, chiach, ciach? Nie!
Nic nie stoi na przeszkodzie, aby jako argument do metody split przekazać wyrażenie regularne.

A może by tak nie ściągać na stronę całej biblioteki jQuery, MooTools, DoJo, czy też innej, której używasz, jeśli potrzebujesz tylko możliwości selekcji elementów w drzewie DOM?

Jeśli wykorzystanie przez Ciebie jednej ze wspomnianych bibliotek ogranicza się wyłącznie (lub prawie) do wybierania elementów na podstawie zadanego selektora, to ta biblioteka jest Ci zupełnie niepotrzebna.

Chcesz wybrać grupę elementów?
W jQuery robiłeś to pewnie tak:

var linki = $('#sekcja1 div.blok a');

aby wybrać wszystkie linki zawarte w div(ach) z klasą blok, zawarty/e w elemencie o id=sekcja1.