Custom field translation

[micahmills]

Added Translation fields to Custom Fields so you can add a custom translation to an existing key, or add a translation to your custom fields.

I also updated all (or I got them all) of the usages of the label key on the front-end.

[micahmills]

I am not sure why the build failed, If anyone can figure out what the error in TravisCI is that would be a huge help.

[corsacca]

Thanks @micahmills
I briefly looked through the changes. Looks like a lot of front end checks.
I wonder about replacing the translations when the fields object is being build instead of on the front end.

[corsacca]

I'm also not sure why the travis version of the script.min.js is different than the one we are generating. I'll look at it more later

[micahmills]

replacing the translation when the object is created is probably a better option. I am not actually sure where/when that object is created though.

[corsacca]

Have a look at the dt_custom_fields_settings_after_combine filter.
example: dt-contacts/contacts-post-type.php:753

[micahmills]

I am not sure why the minified script files are failing in Travis. I have merged master in and run gulp. Everything seems to be up to date, but Travis doesn't like it for some reason.

[micahmills]

@mikeallbutt found a bug with this PR as it stands. If the DT instance is in Language A, but the user has his language set to Language B. If he goes into the Admin and adds a translation for Language B it will appear in the default field as well. This is because we are using the "dt_custom_fields_settings_after_combine" hook in dt-contacts/contacts-post-type.php:753 to update the object label with the translated version when we create the Object, that then populates the default text input instead of the the actual default language. If the user then saves the input in this state it will make the translation the default label instead of the original.

[corsacca]

I think a pull from master will resolve the phpcs issue.
We had removed the package-lock.json, but travis needs it so it uses the same packages.

[micahmills]

so far this makes the Custom Fields, and Custom Tiles translatable in the Admin UI. I just need to add the Custom Lists.

[micahmills]

@mikeallbutt found a bug with this PR as it stands. If the DT instance is in Language A, but the user has his language set to Language B. If he goes into the Admin and adds a translation for Language B it will appear in the default field as well. This is because we are using the "dt_custom_fields_settings_after_combine" hook in dt-contacts/contacts-post-type.php:753 to update the object label with the translated version when we create the Object, that then populates the default text input instead of the the actual default language. If the user then saves the input in this state it will make the translation the default label instead of the original.

This bug should be fixed as well. You can now change the default label if your user isn't using the default language.

[corsacca]

Brilliant @micahmills !
I'd love to see the changes also applied in the groups-post-type.php and dt-posts>custom-post-type.php. I think it would just be adding the filters.

[corsacca]

Just for debugging and aesthetics (and maybe clarity when reading the code):
What do you think about nesting the translations under a "translations" key?

[corsacca]

For some reason i can't set the translation for group field names like group type.
It refreshes and stays blank:

[corsacca]

@micahmills i look forward to using this feature! thank you!