I have my site in both English and German. For my Extbase records, I configure all the fields with:
'l10n_mode' => 'exclude',
'l10n_display' => 'defaultAsReadonly',
except those input and text fields which contain text that I want to translate. This works as expected at a lower (TCA) level: If I want to change any of the excluded fields I change it in the English (default) record and the change is also reflected in the German record.
But I have a big problem in the frontend, in the Controller Update actions: when I'm visiting my website in German, and I update a German record changing one of the excluded fields, this change is only done for the German record and doesn't get reflected in the English record. Moreover, if I then change anything in the record through the backend, this change I made to the German record's field gets overwritten by the English record's value and therefore lost.
Is there any way to solve this kind of situations in an idiomatic manner for TYPO3's Extbase?
Thanks a lot in advance!
Related
I am working on zf2 translation.I have added some fields in database,I added translated string for each field for each language.
But User can also add field.Suppose user is in English local and added A field in English language only,But later some user accessed the website and he or she knows Spanish,In this case for this user that field which previous user added should displayed in Spanish language.
So in this case how to manage dynamic field translation.Can any one help me for this issue.
I'm sure this is an easy fix but I can't seem to find it. I just have a form, that will be a subform of another, that needs to display the results of a query.
The query is simple enough, just displays all fields of records that fall between specified dates. The query works great, but when I attach it to the form as its record source it doesn't display the data. I can see the correct amount of record selectors so I know its understanding the query but its as if all fields are hidden!
I have also tried building a query to the forms record source that was simply Select query.* From query. Oddly I have had this working before but I had to specify every field. What I mean is:
Select title From query
Select type From query
Select date From query
...
And so on for all the fields but this seems foolish, can anyone think of what I may be doing wrong?
Thanks in advance!
Edit, forgot to mention I also tried the foolish solution that I mentioned above and it didn't work so its definitely some issue that I'm not seeing, some property that's probably not appropriately set
#sshekhar well its not really code at the moment I'm using Access 2010. I have a form that needs to display a subform that executes this query of displaying records that have a data field that fall between dates specified by the user. The query works and displays the correct records, but the form that it is attached to only shows the record selectors and all the fields appear to be "hidden." I thought it may be one of the form's properties set incorrectly but I checked on the test form from another database that I used and each have what appears to be identical settings. So I'm at a loss!
So it turns out even though I using a query that holds all the fields it will not display the content unless you go to the Add Existing Fields and add all the the fields you want to see. This seems really silly especially when the results in the query but at least its working now.
I had this problem and discovered that having the property DataEntry set to YES will only display new records. From Microsoft Help:
You can use the DataEntry property to specify whether a bound form
opens to allow data entry only. The Data Entry property doesn't
determine whether records can be added; it only determines whether
existing records are displayed. Read/write Boolean.
I needed to create a input mask for a jQuery datepicker in my Rails app, where the first form field uses m/d/yy format and the datepicker populates a hidden input with the proper database format.
I was using SimpleForm, and so I extended my own input so that the input is preceded by the mask.
I got everything set up and when checking out the browser, it all just worked well before I thought I would be done.
The form ends up with two inputs for the same attribute, each with the same id and name. I never thought this would work. Checking the development log I only see one date getting submitted, the second of the two which is the one that has the proper format for the database.
Is this all okay? Should I take some extra steps even though this appears to work fine, and more importantly, can someone explain what's going on under the hood that results in this behavior?
Thanks!!
Rails uses the Hash params to store fields submitted. When you declare two or more inputs using the same name, it happens the same as if you do something like
h=Hash.new
h[:name]="foo"
h[:name]="bar"
Result is bar because the foo was overwritten. So the "winner" is always the field value which the browser last appended to postdata.
But if I where you, I would not rely on the browser that the second field gets appended at last.
In my application I'm currently using forms which allow to enter Title and Slug fields. Now I've been struggling with the slugs thing for a while because I can never decide once and for all how to handle them.
1) Make Title and Slug indenpendent
Should I allow users to enter both Title and Slug separetely? This is what I had first. I also had an option that if user did not enter the Slug it was derived from the Title. If both were enter, the Slug field took precedence.
2) Derive Slug from Title, when content is inserted that's it for the Slug, no more changes
Then, I switched to only Title field and derive Slug from title. While doing it I found out that now I have to change all the forms that allowed user to enter a slug. This way of doing it also prevents users to change Slugs - they can change the Title but it has no effect on the Slug. You can think of it like Slug is uniqued ID.
3) Now I'm thinking again of allowing users to change slug
Though I don't think it is all that useful. How many times does the content that someone already added, spent time on writing it, even require a change of either Title or slug? I don't think it is that many times.
The biggest problem with the 3rd option is that If I use Slugs as IDs, I need to update the reference all over the place when Slug changes. Or maintain a table that would contain somekind of Slug history.
What are you thoughts on these, I hope, valid questions?
If someone has a sample DB design for this, it would be appreciated if you share it here.
If you decide to allow users to edit slugs, you could include the ID of the content in the URL and perform a 301 Moved Permanently when the slug doesn't match the current slug. E.g., if /product/42/black-bucket/ is now /product/42/shiny-black-bucket/, you could redirect to the new slug. I saw recommendations not to allow arbitrary slugs for your URLs, as this breaks the concept of canonical links for search engine crawlers and allows malicious folks to game your results.
I've just been going through all of this with a client, sorting out the rules around the URLs, etc.
Your slug should be at the very least slightly independent of the title, if only to ensure that you can take out standard "stop words" - most SEO's would recommend that the page path be as keyword rich as possible so a page title of:
Darling: we will cut deeper and tougher than Thatcher
Could become a slug of:
alistair-darling-cut-deeper-margaret-thatcher
But if possible, you should automate it as much as possible when the author is creating the post, so as they tab/move out of the Title field you populate the Slug/Name/Path field with a string that has removed all symbols, (ideally) removed an agreed list of stop words and replaced spaces with hyphens, so the automated slug from that title could be:
darling-will-cut-deeper-tougher-than-thatcher
But you need to give the author the ability to tweak beyond that.
We've also specified that this automation will only happen when the author creates the post, so subsequent edits would not automatically change the slug, to ensure that we don't suffer from external link rot (the CMS we're using manages all the internal links).
The only time the author should really be changing the slug would be if they'd published a typo, or something libellous.
Personally I would suggest letting the user edit the title and the other contents of the record for the page. Once they have done this you can derive the slug from the title (or anything else you feel like). If they change the title then the slug can change but you could keep a record of the old slugs associated with the same page. If someone comes to the site with an old slug then you can send them 301 response and redirect them to the new page. This would be via an interception page handled by your routing.
Another question would be if they are changing the title, surely it's a new page with new content and with a new slug?
Thoughts?
How about only allowing the user to edit the title or slug while the page is in draft. When the page is published the title and slug become permanent.
Or as #WestDiscGolf said, keep a record of all old slugs and send a redirect.
Let say i have a basic tagging system (for a craiglists "clone") such as:
Tag (id, tagname)
ad(id, title, body)
adTag(tag_id, article_id)
This will fit for a non-localized website but what will be the correct aproach for a website that is used by people speaking diferent languages?
Users probably will post ads in diferent languages in one same local area, so, maybe i should make some kind of synonym system that considers "job" and "trabajo" the same tag? But, what about users that only want to see ads in one language?
Catering for tags for all the different languages is probably just going to be trouble. Going with the idea where you treat all variations of a tag as one single type will probably simplify a lot of the issues (so you don't need to keep track of language-tag mappings on the fly, just do the conversion once and be done with it). If the user needs to search by language later on, then just stick a meta-tag for that particular language on when you save the post.
Of course, that leaves the question of what happens when a user uses tags from multiple languages... but I suppose you can always enforce one single language or something.
I can think of two possible solutions:
Add language field: Tag (id, tagname, lang) where you can specify the language for the tag
Change Tag to Tag(id) and use separate table for tag translations tagTranslations(tag_id, lang, tagname)
Note: But I think this is only needed, if your articles have multiple translations.