Frontend Translation doesn' t work: Another article from this category has the same alias

[akempkens]

http://www.joomfish.net/forum/viewtopic.php?f=50&p=40275#p40275

According to the specific reproducable description the problem is related to the frontend translation. We need to verify this as it is a core feature.

[klas]

Probably some workaround that makes it work in backend needs to be fired also for front when editing

[akempkens]

Klas I'm pretty sure this is related to the fact within nativeTranslateListArrayWithIDs the variable $onlytransFields ensure the ID is not overwritten. On the other side this jeopardize all other references.

Did you implemented nativeTranslateListArrayWithIDs ?

I'm wondering why this method makes such an effort to ensure only a subset of the existing fields. From my understanding as we store the information within the native table replacing the full content of the objects in the array should be fully acceptable, or I'm mistaken?

The fact that not all fields are plain copied also explains why the language code setting is wrong if you edit the article. This field is not in our translation map at all.

[klas]

We are using only tranlsatable fields as the are usually are not related to the structure - transaltable are fields like like title, description etc - reason is that structure must come from the original object or anything that is related to the structure will break. Menus, categories and since routing, breadcrumbs etc -as soon as you start mixing structure from original and translation everything falls apart. For things to work it has to be either as it is now or - joomla way where each language has totally independent structures. So the mentioned method should most likely stay as it is, perhaps an alternative would be to have structure type so that jf would know to skip those items, but I think it is more intuitive to just skip anything that is not marked as translatable.

Otherwise, if it works on backend it should also work on the frontend with perhaps some modifications I'll try to take a look next week.

[akempkens]

Hi Klas,
I agree partially and based on my analysis I argue that it works in the backend.

You confirmed what I saw as well. I fear that especially for the native tables we are not using the advantages we implemented them for. The generic system is perfect for unknown queries. For loading a known native object I wonder why we should not use our translatable object?

Related the backend/frontend point you made.
According to my research it works in the backend as we either use our own forms or have a very limited interception in the article management.

In the frontend everything is based on the correct article ID and due to the fact this is a non-translatable field this ID is wrong. You see this with the language field as well. I fear tweaking here doesn't make any sense.

I'll create a specific branch for this issue tonight and share it with you. May be we can build the separate structure as you described it. I'm sure we will find people supporting the tests.

• Alex

Am 23.02.2013 um 00:15 schrieb Klas [email protected]:

We are using only tranlsatable fields as the are usually are not related to the structure - transaltable are fields like like title, description etc - reason is that structure must come from the original object or anything that is related to the structure will break. Menus, categories and since routing, breadcrumbs etc -as soon as you start mixing structure from original and translation everything falls apart. For things to work it has to be either as it is now or - joomla way where each language has totally independent structures. So the mentioned method should most likely stay as it is, perhaps an alternative would be to have structure type so that jf would know to skip those items, but I think it is more intuitive to just skip anything that is not marked as translatable.

Otherwise, if it works on backend it should also work on the frontend with perhaps some modifications I'll try to take a look next week.

—
Reply to this email directly or view it on GitHub.

[klas]

Trust me, it won't work if you change the way it works now. E.g. you need to keep original id for routing as joomla uses id to find item and if you use translation id you will get content not found when switching languages.

Don't know what the original intention was, but you simply cannot mix joomfish way with and joomla way, its like creating a combined church for Muslims and Christians. So we are transforming native objects into jomfish ones to keep things consistent. Native only means we are using native tables as storage, it still has joomfish logic of translating only things that are defined in contentelement. Also in my opinion we cannot change this architectural decisions in minor releases (if anything, I would drop this native thing altogether)

For the actual issue in the current enviroment - had some thought yesterday about frontend - what we probably need to do is to have "is this translation" flag/property in the object (haven't looked at the code, could be there is already one), Then, when we detect edit task and object has this flag set we either need to load full translated object in original form or load joomfish component with the same forms as in the backend.

[akempkens]

I get the point.
We might need to find a different solution e.g. when switching in edit mode. The reason is simple. If you use the Joomla article editor you change more fields than just the once we defined to be translated. This is causing our conflicts here. In one of the first JF versions we created special cases for these things and it became a huge hassle to manage. This is why we introduced the translatable objects.
As I said I would love to create a branch to test some scenarios may be we can even develop some tests to proof things working.
Alex

[mixos]

i see these posts are 1 month ago. so i want to ask if front-end editing of translated articles is available in a beta version or if it is still under research... i ve tried some workarounds but dont seem to work...

Thanks!

[akempkens]

We figured out the reason - however have not been able to discuss a working solution yet.

The issue is related to the fact that the routing and the frontend translation create a conflict in our standard processing of the translations. The idea of having a special translation and editing technique needs a bit discussion with the devs.

• Alex

Am 22.03.2013 um 23:40 schrieb Michael [email protected]:

i see these posts are 1 month ago. so i want to ask if front-end editing of translated articles is available in a beta version or if it is still under research... i ve tried some workarounds but dont seem to work...

Thanks!

—
Reply to this email directly or view it on GitHub.