はじめに

※本記事はqiitaに掲載したものの再投稿です。

以前カジキはこういうものを作り、定期実行する環境まで作成しました(環境作成については別途記事にするつもり)

[Python]RSS取得した情報を翻訳してslackに投稿する

で、いざ運用に乗っけてみると、当初心配していたgoogleTransのAPI制限には特に引っかかることはなく使えました。

しかし、翻訳テキストとして渡す中身によって動作が安定しないという別の問題に直面しました。特に、あるRSSサイトが配信しているfeedと相性が悪く、そのfeedでだいたい落ちてしまう。そのfeed自体、翻訳処理をかけるまでにこっちでテキストをだいぶ加工してあげなければならないような、お行儀のよくないサイトではあるんですが、処理が落ちるテキストを調べてもおかしなところが特に見つからずハマりました。(ライブラリ側の置換処理がうまくいっていないことが原因だった模様)

ここは、翻訳APIがgoogleTransという非公式ライブラリである限りは、あまり文句は言えないところです。

まあでも非公式のライブラリにこれ以上を求めるのは酷だなと思い、もうちょっと安定していそうな翻訳APIを検討することになったわけです。

DeepLを選定した理由

というわけで、今回はDeepL APIを試してみます。

翻訳APIは世の中にたくさんありますが、選定した理由は下記です。

  • (1ヶ月の翻訳文字制限はあるけど)無料プランがある
  • 翻訳センスが好き(気分)
  • 翻訳する文章は公開情報(RSS feed)なので、無料版に課されるセキュリティ的な懸念を考慮する必要がない
    • 非公開情報の翻訳など、利用用途によっては有料版を使用したほうがいいということですね。

やってみる

0. DeepLにアカウント登録をする

公式サイトでアカウントを登録します。

登録が完了するとAPI Keyが発行されているので、それを控えておきます。

DeepL Translate: The world’s most accurate translator

1. DeepLのpythonクライアントライブラリをインストールする

pipで入れられます。

pip install deepl

2. DeepL用コードを作成(抜粋)

前回の記事のこの部分について、DeepLクライアントを利用する形に書き換えます。

API Keyの扱いには気をつけてください(Githubなどにあげないよう…)。また、記法の詳細はAPIのリファレンスを参照しましょう。

import deepl
from dataclasses import dataclass
from googletrans import Translator
from typing import List

@dataclass
class DataRssBody():
    title: str
    url: str
    summary: str
    published: str

API_KEY='<自分のDeepLアカウントのAPI Key>'

def translateRssContentsByDeepL(rss_list) -> List[DataRssBody]:
      tr = deepl.Translator(API_KEY)
      translated_contents: List[DataRssBody] = []
      for entry in rss_list:
          title_trans = str(tr.translate_text(entry.title, source_lang='EN', target_lang='JA'))
          summary_trans = str(tr.translate_text(entry.summary, source_lang='EN', target_lang='JA'))
          rss_content_trans = DataRssBody(
              title=title_trans,
              url=entry.url,
              summary=summary_trans,
              published=entry.published
          )
          translated_contents.append(rss_content_trans)
  
      return translated_contents

3. コードを実行してみる

上記コードのentry.titleとtitle_trans、entry.summaryとsummaryを、それぞれprintで出力してみると、それぞれこんな感じです。

だいたいいい感じに翻訳されていますね。(取得元ブログ記事はこちら)

# print(entry.title)
A Boom in Open Source Jobs Is Here. But Who Will Fill Them?

# print(title_trans)
オープンソースジョブのブームが到来。しかし、誰がそれを埋めるのでしょうか？

# print(entry.summary)
'USTIN, TEX. — Forty-one percent of organizations in a new survey said they expect to increase hiring for open source roles this year. But the study, released in June by the and online learning platform edX during the foundation’s Open Source Summit North America, also found that 93% of employers surveyed said they struggle to [&#8230;]The post A Boom in Open Source Jobs Is Here.But Who Will Fill'

# print(summary)
'テネシー州ユスティン- 新しい調査の結果、41%の組織が、今年はオープンソースの職務の雇用を増やす見込みであると回答しました。しかし、財団のオープンソースサミットノースアメリカの間に、オンライン学習プラットフォームedXによって6月にリリースされた調査では、調査対象の雇用者の93％が、彼らは[&#8230;]に苦労していると述べたことも明らかになった投稿オープンソースジョブのブームがここにある。しかし、誰が埋めるのだろう'

おわりに(無関係)

カジキのITキャリアのベースはシステム(インフラ)エンジニアなので、(全てのシステムエンジニアがそうではないとは思いますが)プログラムを書くとなると、書き捨てのスクリプトを作る発想になります。Python触りはじめてからも長いこと同じ発想でした。カジキはコード構造を意識して書くみたいな海域(技術文化)では育ってきてなかったのです。動きゃあいいやろという過激思想。

このRSS翻訳処理の初期コーディングの頃は、ちょうど「コードは読みやすさや構造が大事」みたいな本を読んで影響を受けまして(単純)、初期コーディングではコード全体のコンポーネント構造を意識していました。

で、それが功を奏して、googleTrans → DeepLへの処理移行がほぼ関数の入れ替えだけで済み、修正が比較的楽だったと感じました。アプリケーションコードもシステムも将来を見越した設計が大事ということは同じなんだなあと思いました。この辺もいつか記事にしたいですね。

参考文献

DeepL API