The result of last night’s coding is a little field plugin which displays the translation status of a page. By clicking one of the „language status tags“ you can switch to the edit form in the corresponding language.
Check out https://github.com/flokosiol/kirby-translations for more information 
Good idea 
How about extending it to check if all fields have been translated, not just the content file created? Just saying…
How do you think that kind of feature would look like? Something like this?
5/12 [check icon]
What about select boxes? Should they be skipped? They would have them same key in all languages?
At the moment I’m just checking, if a .txt file for the language exists. That’s pretty simple
What about fields which have the same value in different languages, e.g. the title of a ‘Download’ button? What is the criteria for a field to get the „translated“ status?
Another idea I want to implement is to add a possibility to delete translations without deleting the whole page.
Sorry if I disrupt your conversation, but this would be one idea for it:
fields:
mytranslations:
type: translations
unique:
- my_field1
- my_textarea2
I think it needs to manually add what fields to check. In this example The fields in unique is checked, the rest is not counted. (Unique as in unique in their own language) Maybe there is a better key name for it than unique.
… or just filter out fields with the option translate: false
But doesn’t this duplicate the translate: false option that is already natively supported in blueprints?
… but there is still the question when to consider a field as translated?!
translate is false (skip check)I agree on that one. Hard to define. If say a price can be different from one language to another but you want to keep it the same for one page…
What about trusting the user instead: the field becomes a checkbox to manually check after the translation is complete ?
I’d just say “when the field is not empty”.
I might be wrong, but doesn’t a freshly created translation automatically import the field contents of the default language? It wouldn’t be empty then.
And then there are the fields that are empty in the default language, too.
Tricky.
Yes, exactly, as soon as you save, the non-default language inherits all the content from the default language. Checking for empty field content therefore does not really make sense. So in general, you would have to compare field content (but you can’t even rely on that). But that get’s tricky for non-translatable fields (that information could be retrieved from the blueprint) and fields that might have the same content, which would indeed require some user interaction.
I knew it was going to get tricky, indeed…
So far, I think there are two options when a page could be considered as untranslated:
.txt file was created (user saved it), but all field values are equal to the default language (though I’m not sure why someone should do this 
)Furthermore I thought about implementing a third state (orange) which indicates that the .txt file has been created but the page isn’t finally translated.
Btw: Thanks for all your replies! 
I’m not so sure about the manual button thing. I would personally probably forget to click it sometimes and sometimes I would click it but forget some fields. Then I still need to go back to see where I clicked the button and where I forgot some translations.
Maybe my original idea is the best I can think of after all:
fields:
mytranslations:
type: translations
diff:
- my_field1
- my_textarea2
A page is translated if all the fields in diff is not equal to the original language. Skip when translated is false (even if in diff list).
Diff flags
That way you flag what fields that needs to diff from one language to the original. You would probably add textareas and input text to that list, but probably not select boxes or prices in there.
However I like the states red, orange and green. I think that make sense.
That’s still no guarantee. Someone might have just added one character by chance. Or someone might have written a first sentence, but was then interrupted. Those cases - even if they are edge cases - would then be regarded as false translations.
I must admit that I don’t like the manual checkbox, it adds too much complexity.
Someone might have just added one character by chance. Or someone might have written a first sentence, but was then interrupted.
Yes, that’s true. 
But then there is no guarantee of anything. I mean, maybe I translated everything except the last sentence.
I think it’s just a decision of what rules the plugin should have and go with that. See it as a helper, not as a total truth?
I speak from my personal experience here but we are two people writing on the same blog and often translating over a period of time a long article. If I have started editing the content, it doesn’t mean that I have finished the article although the fields do differ.
@jenstornell, the same way your “status plugin” offers more states than visible / invisible, I think that having that kind of granular control over different languages would be a killer plugin for complex multilingual websites.
@flokosiol, I like where this is going. Please do tell if I can be of any help !
Thanks @Thiousi. Feedback and ideas help a lot and I think there will also be some testing to do in the future …
I think I will definitely add a third state (orange), though I’m not sure in which way (as discussed above). But it may take some time, because I will be on vacation until the end of June.
