Add style to our page

Wow, what a changeset!

This diff contains a lot of noise and might be a challenge to read line-by-line.

The vast majority of these changes are sourced from the Tailwind Toolbox project.

The changes made to the app/views/marketings/index.html.erb, app/views/application/_footer.html.erb app/views/application/_header.html.erb templates (along with their related SVG files), are all sourced from the Screenshot Landing Page template, namely the index.html template file.

Let’s declare some translations

Within the vast collection of new line additions, there are calls to translate to integrate with the internationalization architecture we’ve established in the previous commit.

In addition to changes made to the existing marketings.index.hero translations, this change includes declarations for translations under a new application: key, which corresponds to the templates declared within the app/views/application directory:

--- a/config/locales/en.yml
+++ b/config/locales/en.yml
@@ -30,7 +30,73 @@
 # available at https://guides.rubyonrails.org/i18n.html.

 en:
+  application:
+    footer:
+      links:
+        general: "Links"
+        legal: "Legal"
+        social: "Social"
+        company: "Company"
+
   marketings:
     index:
       hero:
-        title: "Content Authoring"
+        title: "Main Hero Message!"

When possible, this commit declares translations for the copy from the Tailwind Toolbox template. “Static text first” was the guiding principle for whether or not to translate text in the HTML. “Static” is a meaningless concept when you’re pulling HTML from a template. However, in the case of our hypothetical application, “static” copy feels conceptually separate from “dynamic” copy that might be pulled from a model in the database.

For example, the template includes a three-tier Pricing structure. For this example’s case, we can assume that there would be a Tier or Pricing model backed by a database table that we’d pull text from. On the other hand, the marketings#index hero text feels less dynamic, so a translation feels more appropriate.

Translations with an .html key

When determining the text for a given translation key, Rails’ rendering process makes the assumption that the value will be plain text. This means that when it’s interpolated into the template (either by ERB <%= %> syntax or as an argument to another Rails helper), Rails will treat it as unsafe text and sanitize it as a guard against Cross-Site Scripting Attacks XSS.

In cases where the HTML is sourced from the application’s or has already been sanitized, we can skip those guards by declaring keys that end with an .html or _html suffix.

To demonstrate that, this commit contains several keys ending with .html.

What has changed?

We have a visual aesthetic!

Desktop

Mobile

It looks great, but I’m not satisfied with our marketing copy…