Internationalize homepage, header and footer

[ayanchoudhary]

Fixes

Fixes #942 by @brenoferreira

Description

Internationalizes the CC search homepage

Screenshots

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the master branch of the repository.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no
  visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[ayanchoudhary]

@akmadian @kgodey I have completed the task of internationalizing the homepage but I have a query about what I should do with the license types. For eg. on the homepage we have Use Commercially and Modify or Adapt so should I leave them as it is or should I internationalize them as well

[kgodey]

@ayanchoudhary what are the reasons for and against internationalizing them?

[akmadian]

@ayanchoudhary I would also like to hear your thoughts on the pros and cons of internationalizing them.

[ayanchoudhary]

@kgodey @akmadian there aren't any pros and cons related to internationalizing them. The decision rests on the fact whether these phrases are the actual representations of the licenses which are supposed to be definitive or whether these phrases just symbolically represent them

[ayanchoudhary]

@akmadian this branch is already pointing to internationalization so once we the internationalization of the license part gets decided we can merge it into that branch.

[kgodey]

@ayanchoudhary as discussed on Slack, please go ahead and internationalize those strings.

[akmadian]

@ayanchoudhary Please tag me here on github when you are ready for final review :)

[ayanchoudhary]

So I was going through the process of internationalizing the license strings(which are coming from the vuex store), turns out vue-i18n does not provide any inbuilt support for internationalizing vuex-store out of the box. I found (this package built on vue-i18n)[https://github.com/dkfbasel/vuex-i18n] but it hasn't been updated since a year. So should I go ahead with it? @akmadian @kgodey

[zackkrida]

Hi @ayanchoudhary, I am going to look into this even deeper for you, but I may have found a possible solution. The vue-i18n plugin has a mergeLocaleMessage method that can be used to set translation strings on a locale.

This is the basic idea:

<template>
    <p>{{ $t("hello") }}</p>
</template>

<script>
export default {
  name: "any-component",
  mounted() {
    this.$i18n.mergeLocaleMessage("en", {hello: this.$state.store.hello });
  }
};
</script>

I made a small demo here you can check out: I made you a quick demo here: https://codesandbox.io/s/mergelocalemessage-proof-of-concept-rx1j5

Let me know what you think! I believe this solves the issue of storing translation strings inside of vuex, but there may be some details specific to the cc search project that I am missing.

[ayanchoudhary]

Hi @zackkrida thanks for the demo, but the problem which we have here is actually the exact opposite of that from the sandbox, like here we have the translation strings in the normal messages format and the en strings in the store, but I guess we can reverse it to fix that out, let me try it out on the code. Will keep you updated 😃.

[brenoferreira]

@ayanchoudhary ideally, the translations should be in the locale messages JSON file. If they keys are well defined, a function can map the code in the store to the key path of the locale message, something like:

mapFilterCodeToMessageKey(filterCode = 'licenseTypes.commercial') => 'filters.licensesTypes.commercial'

I think trying to "localize the store" is unnecessary complexity and you remove the hardcoded name strings out of the store

[zackkrida]

@brenoferreira thank you so much; I understand the issue now! @ayanchoudhary the basic idea is that you remove the name property out of each item in filterData, and move those name values into the locale messages JSON files, in a shape so they can be mapped by their keys. Something like this (for licenseType as an example:

// would actually just be in the locale json files,  but you get the idea
const messages = {
  en: {
    filters: {
      licenseType: {
        commercial: 'Use commercially',
        modification: "Modify or adapt"
      }
    }
  }
};

thanks again @brenoferreira

[zackkrida]

Given that the license types were included as part of your other PR, this looks complete! Thank you.