dans la table spip_urls en 3.2 il y a une colonne "langue".
J'ai dû rater les discussions qui ont amené à cet ajout mais je me dis que ça doit rendre possible le fait d'avoir des urls par langue pour un même objet, avec des champs <multi> par exemple.
C'était peut être le but d'ailleurs.
Il faudrait donc un jeu d'urls multi, qui génèrerait des #URL_* en fonction du contexte de langue (cookie ?), et dans l'autre sens, le branchement entre une url et son objet.
A voir aussi : la gestion des urls dans le privé, avec la notion d'url principale par objet et par langue donc.
dans la table spip_urls en 3.2 il y a une colonne "langue".
J'ai dû rater les discussions qui ont amené à cet ajout mais je me dis que ça doit rendre possible le fait d'avoir des urls par langue pour un même objet, avec des champs <multi> par exemple.
C'était peut être le but d'ailleurs.
Les logs de ce commit et ceux qui suivent devraient t'être utiles
dans la table spip_urls en 3.2 il y a une colonne "langue".
J'ai dû rater les discussions qui ont amené à cet ajout mais je me dis que ça doit rendre possible le fait d'avoir des urls par langue pour un même objet, avec des champs <multi> par exemple.
C'était peut être le but d'ailleurs.
Il faudrait donc un jeu d'urls multi, qui génèrerait des #URL_* en fonction du contexte de langue (cookie ?), et dans l'autre sens, le branchement entre une url et son objet.
A voir aussi : la gestion des urls dans le privé, avec la notion d'url principale par objet et par langue donc.
dans la table spip_urls en 3.2 il y a une colonne "langue".
J'ai dû rater les discussions qui ont amené à cet ajout mais je me dis
que ça doit rendre possible le fait d'avoir des urls par langue pour
un même objet, avec des champs <multi> par exemple.
C'était peut être le but d'ailleurs.
Il faudrait donc un jeu d'urls multi, qui génèrerait des #URL_* en
fonction du contexte de langue (cookie ?), et dans l'autre sens, le
branchement entre une url et son objet.
A voir aussi : la gestion des urls dans le privé, avec la notion d'url
principale par objet et par langue donc.
dans la table spip_urls en 3.2 il y a une colonne "langue".
J'ai dû rater les discussions qui ont amené à cet ajout mais je me dis
que ça doit rendre possible le fait d'avoir des urls par langue pour
un même objet, avec des champs <multi> par exemple.
C'était peut être le but d'ailleurs.
Il faudrait donc un jeu d'urls multi, qui génèrerait des #URL_* en
fonction du contexte de langue (cookie ?), et dans l'autre sens, le
branchement entre une url et son objet.
A voir aussi : la gestion des urls dans le privé, avec la notion d'url
principale par objet et par langue donc.
dans la table spip_urls en 3.2 il y a une colonne "langue".
J'ai dû rater les discussions qui ont amené à cet ajout mais je me dis
que ça doit rendre possible le fait d'avoir des urls par langue pour
un même objet, avec des champs <multi> par exemple.
C'était peut être le but d'ailleurs.
Il faudrait donc un jeu d'urls multi, qui génèrerait des #URL_* en
fonction du contexte de langue (cookie ?), et dans l'autre sens, le
branchement entre une url et son objet.
A voir aussi : la gestion des urls dans le privé, avec la notion d'url
principale par objet et par langue donc.
D'habitude, c'est moi le troll.
Cédric, tu nous surprendra toujours
PS : et non, il n'y a pas de nom de domaine pro sur mon email
Je parlais du bug, qui est sujet à débat et n'a pas de rapport avec la discussion qui concerne les URLs (et ne parlait même pas de multi sur les rubriques)
Je parlais du bug, qui est sujet à débat et n'a pas de rapport avec la discussion qui concerne les URLs (et ne parlait même pas de multi sur les rubriques)
C'est gentil de prendre la défense de ton petit camarade.
Mais je le crois tout à fait capable de discerner lui-même si mon intervention était pertinente pour lui ou non.
Et assez grand pour le dire lui-même.
Je parlais du bug, qui est sujet à débat et n'a pas de rapport avec la
discussion qui concerne les URLs (et ne parlait même pas de multi sur
les rubriques)
C'est gentil de prendre la défense de ton petit camarade.
Mais je le crois tout à fait capable de discerner lui-même si mon
intervention était pertinente pour lui ou non.
Et assez grand pour le dire lui-même.
Mais moi j'ai aussi le droit de dire que ces interventions répétitives (oui il y a un pattern qui me saute aux yeux) m'agacent.
Bon, j'ai bien testé tout ça, c'est super, ça marche bien.
Mais cerdic, pour quelle raison la liste des langues qui servent à générer les urls est issue de la méta *langues_utilisees* et pas *langues_multilingue* ?
Bon, j'ai bien testé tout ça, c'est super, ça marche bien.
Mais cerdic, pour quelle raison la liste des langues qui servent à générer les urls est issue de la méta *langues_utilisees* et pas *langues_multilingue* ?
Dans mon cas j'ai un site entièrement basé sur des champs multi (rubriques et articles), sans menus de langues ni lien de traductions.
Du coup, langues_utilisees ne contient que la langue principale (fr), et les urls ne sont pas générées pour toutes les langues.
Tiens, en creusant je lève un autre lièvre :
Ici, tu vérifies si la langue est bien une langue connue :
url_verifier_langue() se base sur la méta *langues_proposees* :
Mais cette méta ne contient pas toutes les langues proposées dans /?exec=configurer_multilinguisme
Je m'en suis rendu compte en testant plusieurs langues, j'avais coché le Wolof (me demande pas pourquoi), qui n'est pas dans la méta langues_proposees, et les urls arbos renvoyaient en 404 dans cette langue.
nicod_ a écrit :
> Le 06/09/2017 à 13:15, nicod_ a écrit :
>> Bon, j'ai bien testé tout ça, c'est super, ça marche bien.
>>
>> Mais cerdic, pour quelle raison la liste des langues qui servent à
>> générer les urls est issue de la méta *langues_utilisees* et pas
>> *langues_multilingue* ?
>>
>> https://zone.spip.org/trac/spip-zone/browser/core/plugins/urls_etendues/urls/arbo.php#L440
>>
>> Dans mon cas j'ai un site entièrement basé sur des champs multi
>> (rubriques et articles), sans menus de langues ni lien de traductions.
>>
>> Du coup, langues_utilisees ne contient que la langue principale (fr),
>> et les urls ne sont pas générées pour toutes les langues.
En effet, dans mon cas test (site avec des trads), c'est équivalent, mais si c'est mieux sur un site tout en multi d'utiliser langues_multilingue on peut changer.
>
> Tiens, en creusant je lève un autre lièvre :
>
> Ici, tu vérifies si la langue est bien une langue connue :
> https://zone.spip.org/trac/spip-zone/browser/core/plugins/urls_etendues/urls/arbo.php#L748
En effet, dans mon cas test (site avec des trads), c'est équivalent, mais si c'est mieux sur un site tout en multi d'utiliser langues_multilingue on peut changer.
Il me semble, ce serait plus complet.
> Mais cette méta ne contient pas toutes les langues proposées dans
> /?exec=configurer_multilinguisme
Ah il faudrait plutôt vérifier dans $GLOBALS['codes_langues'] alors ?
Probablement, avec un include_spip('inc/lang_liste') pour la déclarer.
Si je comprends bien, la méta langues_proposees ne liste que les langues qui ont une traduction publique (celles qui sont soulignées sur exec=configurer_multilinguisme).
En effet, dans mon cas test (site avec des trads), c'est équivalent, mais si c'est mieux sur un site tout en multi d'utiliser langues_multilingue on peut changer.
Il me semble, ce serait plus complet.
> Mais cette méta ne contient pas toutes les langues proposées dans
> /?exec=configurer_multilinguisme
Ah il faudrait plutôt vérifier dans $GLOBALS['codes_langues'] alors ?
Probablement, avec un include_spip('inc/lang_liste') pour la déclarer.
Si je comprends bien, la méta langues_proposees ne liste que les langues qui ont une traduction publique (celles qui sont soulignées sur exec=configurer_multilinguisme).
Chez moi ça marche, je commit ces deux modifs si tu veux.
Le 6 sept. 2017 à 20:29, nicod_ <nicolas.dorigny@gmail.com> a écrit :
Le 06/09/2017 à 14:58, nicod_ a écrit :
Le 06/09/2017 à 14:48, Cédric Morin a écrit :
En effet, dans mon cas test (site avec des trads), c'est équivalent, mais si c'est mieux sur un site tout en multi d'utiliser langues_multilingue on peut changer.
Il me semble, ce serait plus complet.
> Mais cette méta ne contient pas toutes les langues proposées dans
> /?exec=configurer_multilinguisme
Ah il faudrait plutôt vérifier dans $GLOBALS['codes_langues'] alors ?
Probablement, avec un include_spip('inc/lang_liste') pour la déclarer.
Si je comprends bien, la méta langues_proposees ne liste que les langues qui ont une traduction publique (celles qui sont soulignées sur exec=configurer_multilinguisme).
Chez moi ça marche, je commit ces deux modifs si tu veux.
En testant et à l'usage, je remarque encore des points à corriger :
- quand on supprime une des urls de langue depuis le privé, elle n'est pas regénérée
- on ne peut pas non plus la recréer ou créer une nouvelle url pour une langue, il n'y a pas de choix de la langue dans le formulaire editer_url
- si on crée une nouvelle url, elle devient donc url perma sans langue définie, et elle prend le pas sur toutes les autres urls liées à une langue
Je continue à mettre le nez dedans, parce que c'est achement bien quand même, mais les urls arbo c'est un peu compliqué, et je vais peut être en faire des tickets pour ne pas oublier.
En testant et à l'usage, je remarque encore des points à corriger :
- quand on supprime une des urls de langue depuis le privé, elle n'est
pas regénérée
oui mais c'est normal, on ne sait pas si l'utilisateur veut supprimer vraiment cette URL de cette langue pour retomber sur l'URL par défaut pour cette langue
- on ne peut pas non plus la recréer ou créer une nouvelle url pour une
langue, il n'y a pas de choix de la langue dans le formulaire editer_url
pour la définition de l'URL d'une langue donnée c'est
en:my-page
dans le formulaire
(oui c'est un hack)
- si on crée une nouvelle url, elle devient donc url perma sans langue
définie, et elle prend le pas sur toutes les autres urls liées à une langue
oui si tu créé une URL perma, il faut le faire pour toutes les langues
Je continue à mettre le nez dedans, parce que c'est achement bien quand
même, mais les urls arbo c'est un peu compliqué,
oui et ça commence à poser des soucis de perf je crois, la table des urls se complique, grossis, et j'ai des sites sur lesquels ça génère beaucoup de requêtes dont je ne suis pas sur de l'optimalité.
Il faudra y regarder de près mais je n'ai pas encore eu le temps
- on ne peut pas non plus la recréer ou créer une nouvelle url pour une
langue, il n'y a pas de choix de la langue dans le formulaire editer_url
pour la définition de l'URL d'une langue donnée c'est
en:my-page
dans le formulaire
(oui c'est un hack)
Oh le fourbe
Ça mériterait peut être une interface plus explicite, un select de la langue par exemple... à voir.
Du coup ça éclaircit les deux autres points que j'avais notés.
Je continue à mettre le nez dedans, parce que c'est achement bien quand
même, mais les urls arbo c'est un peu compliqué,
oui et ça commence à poser des soucis de perf je crois, la table des urls se complique, grossis, et j'ai des sites sur lesquels ça génère beaucoup de requêtes dont je ne suis pas sur de l'optimalité.
Il faudra y regarder de près mais je n'ai pas encore eu le temps
Oh le fourbe
Ça mériterait peut être une interface plus explicite, un select de la
langue par exemple... à voir.
J'ai pas voulu complexifier le code et l'interface pour un cas exotique utilisé par peu de monde, d'où la fourberie, mais si tout ça devient robuste et utilisé on pourra voir à faire plus usable
