The po plugin needs to be updated to match the urlto sub API and
signature changes. Else a wiki with the po plugin enabled cannot be
refreshed / rebuilt because of (correct) Perl errors.
My po branch contains a fix.
--[[intrigeri]]
The commit looks sane to me, for what it's worth. Joey, please
consider merging? --[[smcv]]
Merged. --[[Joey]]
Also, I fear the lack of any useful $from parameter might break some
l10n'd link niceness when using po_link_to = current but I have not
investigated this yet.
--[[intrigeri]]
If urlto is called without a second parameter, it means we need
a URL valid from either the CGI URL or any page in the wiki,
(so we'd previously have set the third parameter true), but we
don't necessarily need an absolute URL - so return what you'd
have returned if asked for an absolute URL, but looking like
/bugs/ rather than http://ikiwiki.info/bugs/ if possible.
It looks as though beautify_urlpath under po_link_to = current,
and 3-argument urlto, aren't tested by t/po.t - perhaps you
could add some test cases there? To test 3-argument urlto you'd
need to add $config{baseurl} = "http://example.com" or
something. --[[smcv]]
I'm leaving this bug report open until this can be checked. --[[Joey]]
My ready/urlto branch improves the test coverage. The bugfix from
that branch fixes most of po too, but leaves behind some perhaps
less-than-ideal behaviour: links where the current language is unknown,
with po_link_to = current, always go to the master language,
whereas perhaps it'd be better to go to the negotiated language in
this case? --[[smcv]]
Thanks for taking care, thanks for these improvements!
OTOH I consider any of these behaviours (either the brand new one
= link to master language, or the alternative one = link to
negotiated) as a regression. Any of these is contrary to what
po_link_to = current is supposed to do according to the
documentation.
Let's be less technical, let me display my practical usecase
(making this possible was one of the main reasons I initially
implemented po_link_to = current).
Summary: the current state of things is an annoying regression
and it needs to be fixed.
Context: I participate in building a Live system based on Debian
Live; the project's multilingual website
(T(A)ILS is built using ikiwiki. A
static / offline copy is shipped on ISO images; this is the way
end-user documentation lands on the CDs. Note that no webserver
runs on the Live system to serve this wiki, so po_link_to = current is compulsory. A user can choose her preferred language
at boot time. Depending on her decision, The desktop shortcut
that points to the embedded documentation (i.e. static wiki)
links to a different entry point depending on the chosen
language.
The previous (documented) behaviour was deadly simple: if I am
presented a page in English (master language) it means it does
not exist in my preferred language; the computer always displays
me the best available version according to my needs. The new
behaviour brings a troubling seemingly random factor into the
user navigation experience and IMHO is a mess from a web
ergonomics point of view (no content negotiation available,
remember): I sometimes am shown an English page although it is
fully translated in my language one click away, and on the
contrary I sometimes I am shown the optimal page. This, is, well,
interesting. This practically forces the non-English speaking
website visitor to check the otherlanguages list on every single
page to make sure herself there is nothing better available,
and sometimes click on her preferred language link to get a page
she actually can read.
I unfortunately might not be able to dedicate the needed time to
help fix this in a timely manner, so I don't want to urge anyone.
Take care! --[[intrigeri]]
I can see why this is bad, but to the best of my knowledge it's
not a regression: each of the calls to 1-argument urlto was
previously a call to 3-argument urlto, which always produces
a fully absolute URL, so in either case there isn't enough
context to know the current language. Links that were previously
2-argument urlto still have a defined second argument;
I've just edited plugins/write to clarify why the second
argument should be provided whenever possible. --[[smcv]]
Ok. I am sorry for the burden that arose from my
misunderstanding. No need to keep this bug open then =>
[[done]] --[[intrigeri]]
|
