I’ve got an “Article” content type with Internationalization enabled, however, when trying to fill my english version I don’t see the “Fill in from another locale” as it is with my “Product” content type. Any idea where I should look at ?
Same issue i fetch also,
any one have solution ?
Same I cannot find that option as well. What is the condition that would show this button?
Hi all,
I’ve found how it works :
While I’ve found the solution, I’ve also created a python script to duplicate an entry from one local to another. I’m posting it here in case it could be useful to someone who need a scriptable tool.
import requests
import json
import sys, getopt
urlBase = "COPY HERE YOUR STRAPI URL BASE: https://strapi.mydomain.com/api"
token = "COPY HERE YOUR API KEY WITH WRITE ACCESS"
# ---------------
# --- duplicate
# ---------------
def duplicate(contentType, id, source, target):
url = urlBase +"/"+contentType+"s/"+id
print(url)
parameters = {"locale" : source, "populate" : "*"}
headers = {"Authorization": "Bearer "+token}
reponse = requests.get(url,params=parameters, headers=headers)
data = reponse.json()
print(json.dumps(data,indent=4))
# --- manipulate the data
data["data"]["attributes"]["locale"]=target
del data["data"]["attributes"]["createdAt"]
del data["data"]["attributes"]["updatedAt"]
del data["data"]["attributes"]["publishedAt"]
# --- create the same data for new locale
url = urlBase +"/"+contentType+"s/"+id+"/localizations"
reponse = requests.post(url,headers=headers,json=data["data"]["attributes"])
print(json.dumps(data,indent=4))
###############################
# --- MAIN
################################
def main(argv):
opts, args = getopt.getopt(argv,"hc:i:s:t:",["contentType=","contentTypeId=","localeSource=","localeTarget="])
for opt, arg in opts:
if opt == '-h':
print ('''python strapi-duplicate.py --contentType (or -c) <contentType> --contentTypeId (or -i) <id> --localeSource (or -s) <locale> --localeTarget (or -t) <locale>
ex: python strapi-duplicate.py -contentType article -contentTypeId 1 -localeSource fr -localeTarget en ''')
sys.exit()
elif opt in ("-c", "--contentType"):
contentType = arg
elif opt in ("-i", "--contentTypeId"):
id = arg
elif opt in ("-s", "--localeSource"):
source = arg
elif opt in ("-t", "--localeTarget"):
target = arg
else:
print("Error: unknown option "+opt)
sys.exit(1)
duplicate(contentType, id, source, target)
###############
# --- bootstrap to run as a script
###############
if __name__ == "__main__":
main(sys.argv[1:])
And some usage exemples :
python strapi-duplicate.py -h
python strapi-duplicate.py -c article -i 1 -s fr -t de
python strapi-duplicate.py -contentType article -contentTypeId 1 -localeSource fr -localeTarget en
This is not a good solution for me. Have you tried this with collection types with fields that are non localized? Meaning fields that should be the same for all localization.
In my case, I have a bunch (eg, images that should be shared accross all localizations). So, if I move forward with your suggestion, I end up loosing all values on fields that are not localized, and it’s very frustrating. I’ll expand the steps you outlined:
Anyone experiencing the same? I’m currently on strapi 4.14.4
Thanks
Hi @roygardo ,
It was already strange to me that a save is a required step to see the “Fill in from another Locale”.
It’s even more strange when you tell me that unlocalized fields are re-initialized.
What I understand is that when clicking on “Fill in from another Locale”, the unlocalized fields are then not filled in ?
Probably a good topic for the Strapi’s developers.
Hey Noel,
Yeah, the unlocalized fields are not filled in, so when you hit save, they are empty saved, overwritting the original language. Only the localized fields are kept.
I agree, and already created an issue on this: Non-localized fields data loss when filling from another locale · Issue #18942 · strapi/strapi · GitHub
Thanks for the feedback.
A workaround I found, while this issue remains unresolved, is to use the REST API to create every localized version. This approach does not overwrite existing data in the original language. When you open it, the ‘Fill with another locale’ button is available. By clicking on it, you can populate the common elements. After that, you can edit the localizable fields with the translations!
Ho to do it:
[https://my.strapi.endpoint]/api/[content-type]/:id/localizations
sending a JSON post as follows:
{ "locale": "es-ES", }
Just posting to add another one that has this issue, seems a major issue. My customer is wondering why all his data in English is deleted when he clicks Fill in From Another Locale.
Showing Fill in From Another Locale without saving should solve it, although the risk is still there. Maybe only overwrite other fields when saving in the default language, not the others.
I have found another and in my opinion better workaround until its fixed!
When you switch to another locale, instead of adding in data and then saving to reveal the “Fill in From Another Locale” link, just hit refresh instead. Hey presto, it’s copied the unlocalized data over already and then reveals the Fill in From link.
My hunch is when you switch to a locale it does copy the unlocalized data over at that point, but perhaps the page is rendered before its saved. Refreshing then shows the data. So when I fill in the internationalized field and save, the original data is still there because there are no empty fields to copy back. But strangly if you switch to a locale, refresh to get the data, then do not save but go to another locale and back, the one you just refreshed is not saved. Its empty again. So you must save it after the refresh. I guess the data is only populated in the browser and just not filling in the fields until a refresh, weirdly.
Of course, there is still a risk here that you do accidentally fill a field or click save before refreshing, in which case it copies all the empty data back. I bet you’ll do it on the last of the 20 locales you have 
Edit: darn it, Sevbauer beat me to it 2 weeks ago on Github Non-localized fields data loss when filling from another locale · Issue #18942 · strapi/strapi · GitHub
