Search issues with languages and SEF

I'm using FC 3 Beta 6b, latest sh404SEF and Falang and would like to solve the following 3 issues:

1.
With Joomla search I am able to have the menu name as the only path to the search page.
I've set a published menu in Portuguese (default language) with the name "pesquisa" and in English with the name "search".
So, in default language (Portugueses) the url is www.site.com/ pesquisa?searchword=example
and in English the url is www.site.com/ search?searchword=example

If I choose FC search module and menu, with both custom menu item id in the module and Default Manu ItemId in global configuration pointing to the same corresponding menu, the url in Portuguese becomes www.site.com/ pesquisa/search?searchword=example
and in English becomes www.site.com/ search/search?searchword=example

When using sh404SEF, both urls (in Portuguese and English) become www.site.com/ search?searchword=example.

Is it possible to have the same shorter and correctly translated urls given by Joomla native search module and menu?

2.
Can autocomplete work for the non-default languages when using Falang?

3.
As a suggestion, maybe the query parameter "searchword" could be something shorter and independent from any language, in order to avoid mixed languages urls. Maybe you can use the letter "q", such as used by Google: www.site.com/search?q=example

Thanks.

Hello

v3 BETA 7b is ready (will be our RC / Final after bug-fixing):
(do not update a live site yet, it is not as tested as v3 beta6b,
i believe you are making a new one, or testing ?)

github.com/FLEXIcontent/flexicontent-cck/releases

and has an updated SH404SEF plugin,
- now supports all FLEXIcontent viewwith SH404SEF
- adds supports for new category-based views (using category model and category templating)
tags, favourites, myitems, mcats, author


Changes since v3 BETA6b:

- (new field) Author items (links to item view)
- enabled displaying TAGS / Favourites via CATEGORY view (thus using templates, etc)
- frontend category layout switcher as either: (a) drop down select & (b) radio image
- frontend ordering selector now supports custom fields (with flexible configuration)
- categories module
- updated SH404SEF plugin to handle new SEFurls for category view layouts: tags,favs,author,myitems
- added layout templating support to file field (item form), and to International Address field (both item form and item viewing) thus endusers can add more layouts inside the /tmpl/ folder of each field. TODO add description for this and support it for more fields in v3.1+


about your question

1.
-- first part
b]search or pesquisa[/b]
is menu item

and second part is (possibly) the VIEW ?
this could an issue with our search module code, as it seems that it is unneeded / redudant
- open a issue in GitHub it will be accepted with milestone v3.0 (we will examine if it is needed or not)


2.
it should work, did you try it ?


3. yes it makes sense,
also e.g.
- we would also want to possible replace our filter_NN= with e.g. q_fieldname in regards of field filters too

you can open an enhancement issue in GitHub, we will give a milestone of v3.1 to this, too late for v3.0

I would really like to try the new Beta 7b, but the website in now online.

1.
Well, encouraged by your explanation, I searched a little further and guess that you nailed the problem when using Joomla SEF.
I think that In "components/com_flexicontent/helpers/route.php" the build link in the getSearchRoute function should not have the view.
I changed it to this only: And things seem to be working okay without sh404SEF.
Using Joomla SEF only, the menu item is the only thing that appears (pesquisa or search).

Using sh404SEF, I thought that both URLs were still using "search" in both languages, but actually this is not the case as sh404SEF was actually giving this result from its cache. So, with the previous code "$link = 'index.php?option=com_flexicontent&view=search", the action of the form becomes "/search/" (when it should be "/pesquisa/") in the default Portuguese language and just "/en/" (when it should be "/en/search/" in English.

Regarding the first problem (not being translated to Portuguese) I found that you are actually not using the menu item at all, but rather forcing the URL to be "search" in "./components/com_flexicontent/sef_ext/com_flexicontent.php", where it reads "$title [] = $sh_LANG[$shLangIso] . '/';". I guess this is not very nice because there is the need to configure additionally the translations in this file "./components/com_flexicontent/sef_ext/lang/com_flexicontent.php" and, even worse, to worry about having the exact same name given to the search string and to the menu item, in order to have everything set correctly.

Nevertheless:
#1 is there a reason to put the slash in the end of $title [] = $sh_LANG[$shLangIso] ?
#2 couldn't the translations be just like another Joomla language override ?
#3 here are the pt-PT strings:

Regarding the English language and the form action being only "/en/", I don't know what is happening.
Using the code that works with Joomla "$link = 'index.php?option=com_flexicontent" (without the view), sh404SEF now considers this link to be from com_search, which is very odd.

The issue was opened here:
. github.com/FLEXIcontent/flexicontent-cck/issues/210

2.
Yes, already tested and it isn't working.
Should I open an issue?

3.
github.com/FLEXIcontent/flexicontent-cck/issues/209
I'm afraid I don't have permissions to label it as a enhancement, though.

Hello

about 1
-- the change is already made in SH404SEF plugin (wait for a new release)
view=search is removed by the plugin, so you do not need to hack the view.html.php file
and
it will use a language variable so the SH404SEF url will have only 1 /search/ and in proper language

2. The falang data are not added to our index,
will need to give this some thought

3. about
searchword, searchphrase, ordering,
these were replaced with:
q, p, o

also about search view, the text-search query
when using advanced was being revised,
- a big performance lap will be in next release, making text search and field filtering in search view to be of high performance in very large website, and/or when a big number of items are returned by a search, e.g. if your text search much 5000 items,

1.
I will wait for the next release, thanks.

2.
What a pity.
a) Is it possible at least to disable Portuguese words to be displayed in autocomplete when in the English version of the site?
b) If instead of using Falang for items, I use only FC, would it be as easy for end users to insert contents in both languages, I mean, by creating/editing only a single item and translating the translatable fields via tabs?

3.
Thanks, can the beta 7 already be used in production environment?

Hello

please wait for BETA7c is good but does not include performance fix for advanced search plugin, (and also 1 more simple field that we decided to add)

BETA 7nn will be announced in our downloads section when it is done and had some more testing, (start of next week)

-- if you do not have frontend editors, i strongly recommend that you use item associations for items, and use falang for other, menyu, modules etc
(see my other answer in different thread)